Privilege AIMKC2 results

A rule in a prompt
is a request.

Access control for agents has to sit between the model and the resource, evaluated on every call, because anything inside the context window can be argued with.

READ THE DEFINITION ↓GATEWAY · PER-CALL · EGRESS

01 / DEFINITION

The short answer first.

What is AI agent access control?

AI agent access control is the enforcement of what an agent may reach, implemented outside the model. Every tool call is authorised at the moment of use against the identity the agent is acting as, so a model persuaded to attempt something it should not attempt is still refused.

The defining constraint is that the model cannot be part of the enforcement path. Instructions in a system prompt shape behaviour under normal conditions and can be overridden by sufficiently persuasive content in the context window. A control that can be argued with is not a control, which means the boundary has to be code the model calls through rather than text the model reads.

02 / THE GATEWAY PATTERN

One place where every call is checked.

The architecture that holds up in practice puts a single gateway between the agent and every tool. The model produces a structured request; the gateway validates the schema, resolves the caller identity, applies policy, performs the call and records the result. The model never holds a credential and never reaches a resource directly.

Centralising has three effects that matter. Policy is written once rather than per integration. The trajectory log is complete by construction, because every call passes through one place. And revocation is real: removing a capability at the gateway takes effect immediately, without redeploying the agent.

What a gateway checks on every call, and the failure that skipping each one produces.
CheckQuestionIf skipped
SchemaAre the arguments well formed and within range?Free-form arguments become an injection surface of their own
IdentityWho is this call being made on behalf of?The agent's own rights apply, amplifying privilege
AuthorisationMay this identity perform this operation here?Session-start checks miss anything the agent reaches mid-run
QuotaIs this within the volume allowed for one run?Bulk reads are indistinguishable from legitimate use
EgressIs this destination on the allowlist?Any outbound call becomes an exfiltration path
RecordHas the call and its trigger been logged?Incidents cannot be explained afterwards

03 / EGRESS IS THE ONE TO GET RIGHT

The shortest path out.

Data leaves
through a URL.

Most practical exfiltration from an AI system uses an ordinary feature: a fetch, a webhook, an image reference, a link the interface renders.

An agent that can construct an arbitrary outbound request can encode anything it has read into that request. This does not require a write tool, a vulnerability or an unusual capability — a general-purpose HTTP tool is sufficient, and so, in some interfaces, is a markdown image whose URL the client fetches automatically.

The controls are unglamorous and effective: no general-purpose outbound HTTP tool; specific tools for specific destinations; an allowlist enforced at the network layer as well as in application code; and sanitisation of rendered output so client-side fetches cannot be triggered by generated content. For deployments where the material is confidential by default, the strongest version of this control is an environment with no outbound path at all, which is the arrangement described in private AI inference.

04 / WHAT NOT TO RELY ON

Controls that look like controls.
↳ 01

Prompt instructions.

Useful for shaping ordinary behaviour, unreliable against adversarial input. Never the last line of defence for anything that matters.

↳ 02

Input filtering alone.

Blocklists for injection phrases are bypassed by paraphrase, encoding and translation. Worth having, not worth trusting.

↳ 03

Session-start authorisation.

Checking rights once at the beginning of a long run misses everything the agent decides to reach for later.

A guard model that inspects requests before execution is a genuine addition, and it is a filter rather than a boundary: it reduces the rate at which bad calls are attempted without changing what is possible. Its own error rates should be measured before it is credited in a risk assessment, the same way any other model is measured — see AI model evaluation.

05 / QUESTIONS

Asked when designing the enforcement layer.

Why not enforce access control in the system prompt?

+

Because the system prompt shares a channel with untrusted input. Retrieved content can contradict it, and the model has no reliable way to rank instructions by origin. Prompt rules shape default behaviour; they do not constrain a determined input.

Does every tool call really need authorisation?

+

Yes. An agent's target is decided at runtime, so rights checked at session start say nothing about the record it reaches for at step forty. Per-call checks are also what makes revocation immediate.

How does access control interact with retrieval?

+

Retrieval has to be filtered by the same identity as tool calls, ideally at query time. Post-filtering results after generation is too late, because the content has already entered the context. See RAG access control.

Is a guard model a substitute for a gateway?

+

No. A guard model reduces the rate of bad requests; a gateway determines what is possible. They compose well — guard first, enforce always — and the gateway is the part that must hold when the guard is wrong.

What does zero trust mean for AI agents?

+

In practice: no implicit trust from network position or session history, identity verified per call, least privilege by default, and full recording. The agent case adds one twist — the instructions reaching the model may themselves be adversarial, so the identity being verified is the user's, not the model's intent.

Put the boundary
in the architecture.

Privilege AI builds systems where permissions and retrieval boundaries define what a model can access and which actions it can propose.