A local deployment does not remove access control

A local model helps keep documents and conversations out of an external cloud API. Proximity to the server room, however, does not make an agent trusted. If the model process receives a permanent administrator password, a shared CRM key, or a mailbox token, one mistaken command, vulnerable tool, or instruction hidden in its context can turn a useful assistant into a universal service account.

Zero trust states the issue plainly: being inside the corporate network must not create implicit trust. For an AI agent, the practical conclusion is that the model may propose an action, but it should neither store a long-lived secret nor decide whether its own permissions are sufficient.

A safer design separates reasoning from execution. The model expresses its intent in a structured form. A separate gateway checks the user, workload, resource, and operation, then grants the executor short-lived access only to the required system. The permanent password never enters the prompt, conversation history, or model output.

What makes a conventional integration risky

During a quick pilot, developers often put an API key in the agent container's environment and give one service account permission to perform several operations. This is convenient while the agent only reads a test directory. Once email, CRM, files, and payments are connected, the design becomes fragile.

Common failure modes include:

  • one permanent key is used for both reading and changing data;
  • the whole agent process, including third-party libraries and plugins, can access the secret;
  • an incoming user token is forwarded to another service without validation;
  • the model sees a token in a tool result or diagnostic message;
  • a complete Authorization header reaches tracing, logs, or observability systems;
  • disabling an employee does not invalidate an already issued long-lived key;
  • the business cannot establish whether a person, scheduler, or background agent initiated the action.

The official Model Context Protocol authorization specification forbids token passthrough: a token received by an MCP server from a client must not simply be forwarded to a downstream API. The downstream service needs a separate token. The specification also recommends least-privilege scopes, short-lived access tokens, and binding a token to its intended resource. A CRM token should not be accepted by file storage.

A one-operation access architecture

A practical chain contains six roles.

1. **User or business process.** The system knows who requested the task, which company and department the person belongs to, and whether their account remains active.
2. **Workload identity.** The agent container, gateway, and executor have their own machine identities. SPIFFE, for example, supplies workloads with short-lived X.509 or JWT SVIDs and rotates them automatically. The application does not need a permanent authentication secret to call its local Workload API.
3. **Tool and policy gateway.** It receives structured intent rather than arbitrary prose: action, object, fields, justification, and task ID. This is where allowlists, the user's role, environment, limits, and approval requirements are checked.
4. **Credential broker.** After an operation is approved, it exchanges the verified identity for a token with the required audience, scope, and TTL. In an OAuth environment this may be a Security Token Service using RFC 8693; for a database or infrastructure it may be a Vault dynamic secret or a provider-native mechanism.
5. **Deterministic executor.** A separate narrow service calls the CRM, database, or mail system. It keeps the token only in memory, never returns it to the model, and accepts only predefined parameters.
6. **Audit and revocation.** The system records the policy decision, resource, operation, initiator, access lifetime, and result. If a task is cancelled, a user is blocked, or execution fails, access is revoked where the target system supports it.

The model remains useful in this design: it extracts parameters, proposes a plan, and explains the result. Ordinary testable code defines the permission boundary.

User delegation and workload identity are different

Two questions must be kept separate: "who initiated the process?" and "which service is performing this request now?" The first concerns delegated human authority; the second authenticates the workload.

Suppose a sales manager asks the agent to update a customer record. The gateway checks that this manager may change that region and those fields. The executor then proves its own machine identity to the CRM and receives a token for one record or a narrow field set. If a token is issued only to a generic robot account with no connection to the initiator, the audit trail shows the service but loses business context. If the design uses only a user's token and no service identity, it becomes harder to restrict which component may exercise that authority.

A useful audit event links both sides: user, workload, task, policy decision, and resulting call.

What belongs in the audit log

A secret must stay out of the prompt, model context, tool result, HTTP trace, and error text. Incident investigation needs different fields:

  • user and workload identifiers;
  • business task ID and policy version;
  • target resource, operation, and requested scopes;
  • issuance time, TTL, and a lease ID or token hash;
  • evidence of human approval;
  • result code and a partial-execution flag.

Authorization headers and key-like fields should be masked automatically at the gateway. A policy that merely says "do not log tokens" is insufficient: debugging is usually enabled precisely when the system behaves unexpectedly.

Handling failures safely

A short-lived token reduces the exposure window but requires careful execution.

  • If the token expires before the call, the executor obtains another one only after the policy is checked again.
  • If an operation may have completed but its response was lost, the executor must not blindly repeat a write. Use an idempotency key or query the target system's state.
  • If a user is disabled, the broker must stop new issuance and revoke active leases where possible.
  • If the audience is wrong, the target service must reject the token even when its signature is valid.
  • If the broker is unavailable, the agent must not fall back to a stored emergency password. A critical task should stop and be handed to a person.
  • Gateway, broker, and executor clocks must be synchronized, or a short TTL will cause false rejections or an unintended validity window.

For writes, it is useful to separate preparation from approval. The agent prepares a proposed change; a person sees the object and consequences; the gateway issues access only after approval. Sending email, making a payment, deleting data, and bulk changes should each have separate policies and limits.

A minimum viable stack for an SMB

There is no need to build a proprietary identity platform. A pilot can use existing components:

  • the corporate directory or IdP for users;
  • a small tool gateway with JSON schemas and an allowlist;
  • Vault, a cloud STS, or the target system's native temporary-credential mechanism;
  • a separate executor for each risky integration;
  • different identities for development and production;
  • separate read and write permissions;
  • human approval for irreversible actions.

If the target system cannot issue short-lived tokens, the broker can still hide the permanent secret from the agent. The executor retrieves it from protected storage immediately before the call, while the agent sees only a narrow function. This is weaker than true dynamic issuance because the root secret still exists and needs rotation. It nevertheless exposes far less than a key inside the model container.

Modelled economics

Consider a notional company with six integrations, two environments, and separate read and write permissions. Without centralization, this creates up to 24 standing permission sets: 6 × 2 × 2. They may not be 24 different passwords, but they are 24 combinations that must be considered during rotation, audit, and incident response.

With a broker, clients may hold no downstream standing secrets. Trust does not disappear: the broker retains root connections, policies, and issuance authority. Those assets need stronger protection than an ordinary application.

The following is illustrative, not a market quote. At RUB 3,000 per hour, 120 hours of development and integration cost RUB 360,000. Six hours of monthly maintenance add RUB 216,000 per year. The design becomes worthwhile earlier when an agent writes to several systems, handles sensitive data, needs frequent rotation, or requires verifiable audit. For a single read-only directory, a narrow gateway and a dedicated least-privilege account may be sufficient.

A ten-working-day pilot

1. Inventory secrets in one process: where they are stored, who can see them, and what actions they permit.
2. Choose one read-only tool and define its input and output with a strict JSON schema.
3. Set the audience, minimum scopes, TTL, and denial conditions.
4. Connect user and workload identities to the gateway; keep the target system's secret only at the broker or executor.
5. Run at least 50 representative tasks plus negative cases: expired token, wrong resource, disabled user, repeated operation, and an attempt to request an extra field.
6. Measure approved valid calls, false denials, issuance latency, human approvals, and audit completeness.
7. Add write access only afterward. Start with one object or field, then expand permissions based on observed scenarios.

The management test is straightforward: the pilot succeeds not when the agent can call an API, but when neither the model nor its container receives a universal permanent key, and every action can be tied to a person, a policy, and a concrete result.