What is the actual risk with AI that can act?
The risk is not that the model is malicious. It is that the model is confident. An agent can misinterpret a request and act on the wrong record, at the wrong scale, without pausing.
The defence is structural: constrain what the tool layer is capable of doing, rather than relying on the model to behave.
Identity: who is the AI acting as?
An MCP server must never accept the caller's claim about who they are. The session carries a token; the server resolves that token to a real user and a real organization on its own, and every subsequent query is bound to that resolved identity.
This means an agent cannot widen its own access by asking, and prompt injection in a customer message cannot escalate privileges.
Scope: what is this session allowed to touch?
- One organization per session — never a global view.
- Row-level rules enforced in the database, not in application code.
- Read scopes separate from write scopes.
- Sensitive fields excluded from tool responses entirely.
- Tokens that expire rather than long-lived keys.
Confirmation: which actions need a second step?
Anything that moves money, sends an external message, changes a contract or deletes data should be two-phase. The first call returns a preview and a short-lived confirmation token describing exactly what will happen. The second call executes only that described action.
This makes accidental bulk actions structurally difficult rather than merely discouraged.
Audit: what evidence exists afterwards?
Every tool call should produce a durable record: the resolved actor, the organization, the tool name, the entity affected and the outcome. Secrets and tokens are redacted before storage.
Without this, an AI that can act is unreviewable — which makes it unusable in any business that has to answer for its records.