Security
Your agents get the work. Not the keys.
MCP Chats sits between your AI agents and your business. It holds the passwords, checks every request against what you allowed, and keeps a record of every action and decision.
Read what we don’t claim yetYour AI agent
- Read order #5521
- Delete customer #88
- Issue a $740 refund
- Email the customer
MCP Chats
Passwords stay here“Read order #5521”
- Key is valid
- Granted to this process
- Read-only access
Checking…
Your systems
- Orders database
- Customer API
- Payments API
The record
- Waiting for the first request…
Six promises, and how we keep them.
Your organisation is separate
Your processes, data and records are walled off from every other organisation, at the database itself.
How it works
- Every organisation's data is kept apart in the database itself, with row-level security that the application's own database role can't bypass.
- Every query is also scoped to your organisation in code, as a second layer.
Passwords never reach agents
Agents get the answer they need, never the password or key behind it.
How it works
- Database passwords and API keys are encrypted at rest and never sent to an agent or written to logs.
- Agents get named capabilities for a step, not secrets. A key you publish for someone else runs your processes; it doesn't expose your systems.
Access is narrow by default
Nothing is reachable until you choose it, and nothing changes data unless you enabled that action.
How it works
- Nothing in a source is usable until an admin selects it, and nothing is usable by a process until it's granted. Grants are pinned to a version of the source.
- PostgreSQL and SQL Server users are checked for write access and refused if they have it. MongoDB and Cosmos DB access is limited to read operations. Results are limited in rows, size and time.
- An API endpoint that changes data works only if an admin enabled it as a write.
- API calls go only to origins you approved. Private, loopback and cloud-metadata addresses are blocked and redirects are refused, unless an admin explicitly allows private networks.
- Sample values that look sensitive are redacted.
- Every read and write is recorded in the run.
You control every agent's access
Each agent acts as the person who connected it, with the access chosen, and can be switched off at once.
How it works
- A token acts as the person who created it, with their current role, limited to the scope chosen: run, or full.
- Only a hash is stored. The token is shown once, and its format is recognised by secret scanners.
- Tokens never expire by default. You can choose 30, 90 or 365 days instead, unused tokens are flagged after 90 days, and any token can be revoked at any time.
- A token can't create other tokens, and the activity record names the token used.
- An admin can switch off every token in the organisation at once.
- Agent-only keys can be limited to specific processes and paused.
Approvals you can rely on
Every yes is tied to exactly what the person saw, and an email link can't decide anything on its own.
How it works
- Each decision is tied to a frozen snapshot of the evidence the approver saw.
- Email approval links are stored only as a hash, rate-limited, and decide nothing when opened. A second tap changes nothing.
- Links stop working at the approval's due date or after 7 days, and changing an approver's address retires their old links.
- Keys for agent-only accounts and run tokens can't decide approvals.
AI judgement with guardrails
Jev judges against your criteria. When it's unsure, a person decides, and agents can't change its answers.
How it works
- Only processes that use an AI check send anything to Jev, and only the content that check needs.
- An unclear result doesn't pass on its own: it goes to a person or back for rework.
- If Jev is unavailable, a required check waits instead of being skipped.
- Agents can't submit or overwrite Jev's results. Each one is kept with the run, with the question it answered.
Correct when things go wrong
Retries, timeouts and stale work never double an action or slip through unnoticed.
- Retried commands are safe: the same request twice has the effect of one.
- Work handed in on an expired or replaced claim is refused.
- Evidence is checked again when a step is accepted, so an edited record fails.
- An external write with an unknown outcome is recorded as unknown, never retried automatically, and left for a person to resolve.
- A step can send at most 25 emails, and test runs never send email or touch your real systems.
What we don’t claim yet
Honest limits, so you can decide what to route through us.
- No third-party certifications (such as SOC 2 or ISO 27001) yet.
- We're preparing a small, by-request pilot. The hosted service isn't generally available.
- We can only govern what goes through us. If your agent has its own credentials or other tools, MCP Chats can't see or stop what it does with them. Route the work you want governed through processes, and limit the agent's other access.
- What an agent reports is its own claim unless MCP Chats fetched or checked it. The record shows which is which.
Who else handles your data
Our sub-processors, and what each one does.
Microsoft Azure
Hosting, the database, secrets and sending email (Azure Communication Services).
TypeSafe (Jev)
AI checks. When a process uses an AI check, the content that check needs is sent to Jev to be judged. Processes without AI checks send nothing.
Bring the routine you keep explaining.
Join the waitlist for our free pilot. When invited, we’ll help you turn one recurring job into a process and try it with your agent. For solo users and teams, with a setup call to get you started.