Your support agent has a valid service token, your RAG pipeline can query the vector database, and the CRM integration works in staging. Then a customer asks a routine question, the agent retrieves documents from another tenant, or an inherited OAuth grant lets it call a system nobody intended to expose.
That failure isn't primarily a prompt problem. It's a boundary problem. AI access control must establish who may act, who decides whether an action is allowed, and which narrow executor performs it. The model can propose a retrieval or mutation, but an authenticated policy must decide and a downstream service must enforce the decision.
Why AI Access Control Is a Boundary Problem
A production incident often starts with an assumption that sounds reasonable: the agent authenticated successfully, so the request must be authorized. In a multi-tenant RAG system, that assumption can expose every document readable by a shared service account. The vector store sees a valid caller, but it doesn't see the end user, tenant, workspace, or document-level permission that should constrain the query.
The model may answer fluently because it received real documents. That makes the incident harder to spot. The failure isn't necessarily hallucination. It's authorized retrieval under the wrong authority.
Prompt instructions can't repair this boundary. “Only use documents available to the user” is guidance for a probabilistic system, not an authorization decision backed by a trusted identity. A malicious prompt, an indirect instruction in retrieved content, or a tool schema that exposes too much can push the model toward an operation it should never have been able to perform.
Authority before autonomy
The useful design rule is authority-before-autonomy:
- Identity enters the request. The system records the agent, represented user or organization, tenant, task, and delegation chain.
- Trusted state derives scope. The model doesn't choose its own tenant, role, document set, or credential.
- Authenticated policy decides. A policy service evaluates the requested tool, operation, resource, and context.
- A narrow executor performs the action. The downstream API or data service checks the decision again.
- The complete outcome is recorded. Logs preserve what was requested, allowed, executed, and returned.
This separation closes several recurring gaps: over-broad credentials, inherited scopes, indistinguishable retrieval, and approval that can't be tied to the exact operation. Teams improving audit readiness can also use resources such as improving audit readiness with GRC AC to connect access decisions with broader governance processes.
A practical architecture reference for the surrounding components is AI security architecture. The important point isn't which diagram you adopt. It's whether the model remains outside the final authority boundary.
Practical rule: A valid agent identity proves who is calling. It doesn't prove that the caller may access every resource visible to that identity.
The Four Primitives of Authenticated AI Policy
A reliable implementation starts with four primitives. They aren't interchangeable, and removing one usually reopens a specific failure mode.
Per-call identity
Give each agent task a dedicated identity rather than relying on a shared application token. The request should carry enough authenticated context to distinguish the software agent from the human or organization it represents. Preserve that context through tool calls, retrieval requests, asynchronous jobs, and downstream API calls.
A service account can still be useful, but it should represent a bounded workload, not a universal back door. A customer-support agent that reads case history needs a different identity and permission profile from an agent that can change billing settings.
Least-privilege scope
Scope every operation to the smallest useful resource and action. Retrieval may need read access to a tenant-specific collection or a read replica, not database-wide access. A CRM tool may need to read one account's tickets, not search every customer record.
Restrict the operation as well as the resource. "Read customer record" and "delete customer record" must be separate permissions, even when they address the same object. Use short-lived or just-in-time grants for exceptional actions instead of leaving standing access attached to the agent between tasks.
Authenticated policy
The policy decision must resolve server-side from trusted identity and canonical resource state. The model can supply intent, such as “find the latest contract,” but it shouldn't supply the facts that determine which tenant or contract it may access.
A policy decision should be bound to the request and logged before execution. At minimum, preserve the principal, represented user, tenant, tool, operation, resource, policy version, decision, and approval evidence. A memory system also needs explicit boundaries for what state may be recalled and under whose authority, which is why agentic memory for LLM agents belongs in the same control conversation.
Fail-closed execution
If identity, scope, provenance, policy, or approval evidence is missing, the executor should refuse the operation. A “best effort” fallback that queries with the application credential is a privilege escalation disguised as resilience.
The model can still explain that it couldn't retrieve authorized evidence or ask the user to clarify an unresolved constraint. It shouldn't silently substitute a broader identity.
This architecture makes the boundary visible on a whiteboard: identity in, scope derived, policy decides, executor enforces, outcome audited. Each layer has a different responsibility, so a failure in one layer doesn't automatically become authority in the next.
Where Authorization Actually Has to Be Enforced
A middleware check is useful, but it isn't sufficient when the middleware is the only component that understands authorization. If a request can reach the data-owning service through another route, a background worker, a cached query, or an asynchronous job, the boundary has a bypass.
Prompt gating is the weakest position. It may reduce unsuitable tool proposals, but it can't prevent a compromised model from selecting a tool, and it can't protect a direct call against a downstream bug. Middleware policy improves consistency and observability, yet it still depends on every route passing through the middleware.
Enforcement points and their trade-offs
At the LLM boundary, inspect inputs and outputs for sensitive content, instruction injection, and unsupported claims. These filters help reduce unsafe behavior, but they should be treated as content controls rather than authorization. The LLM shouldn't receive unauthorized evidence in the first place.
At the tool boundary, define a permission matrix for each agent task. Tool visibility can fail fast, but hidden tools aren't a security boundary if the executor accepts arbitrary calls. The tool service must authenticate the caller and evaluate the requested operation.
At the downstream service, enforce the rule where the resource is owned. A CRM, payment service, file server, or database should reject a request that lacks the required tenant and resource authority, even if an upstream agent gateway already allowed it.
At the vector store, apply document-level authorization inside the retrieval query. OWASP guidance treats vector stores like other databases and recommends authenticating access, applying authorization to every query, and verifying that every returned document is permitted before it enters the model context. Shared indexes need separate collections, mandatory metadata filters, or dedicated instances per tenant or trust zone, as described in OWASP's multi-tenant isolation guidance.
| Resource | Boundary | Why post-action filtering fails |
|---|---|---|
| Agent identity | Identity provider and token issuer | A later filter can't repair an incorrect principal or delegation chain. |
| Tool | Tool gateway and executor | The operation may already mutate state before a response filter runs. |
| External service | Resource-owning API | Middleware can be bypassed by another route, worker, or integration. |
| Vector index | Retrieval query and document predicate | Unauthorized chunks have already crossed the data boundary before context filtering. |
A useful reference on layered controls is Ciphar on layered access control. The implementation choice should follow the resource type, not the convenience of the current application topology.
Boundary test: If the model can see the data before authorization completes, the system is filtering consequences rather than controlling access.
Building a Tool Permission Matrix
Write the matrix before deploying the agent. Start with a task, not a model. “Resolve a support ticket” is too broad to authorize directly, so decompose it into retrieval, classification, draft generation, and any mutation that requires separate authority.
Map task to identity
Give each material workflow a dedicated identity. A RAG retrieval worker, CRM triage agent, and outbound messaging agent shouldn't inherit the same credentials because they share an application runtime.
Record the represented user or organization separately from the software identity. That distinction matters when the agent acts asynchronously or when several people contribute to a shared task. The executor should be able to answer both “which agent called?” and “whose authority was delegated?”
Restrict resource and operation
For every tool, specify:
- Resource boundary: tenant, workspace, project, collection, table, account, or record.
- Operation: retrieve, create, update, delete, send, publish, or execute.
- Credential mode: read-only, task-scoped, or granted broader rights through an explicit grant.
- Approval requirement: none, conditional, or mandatory for a defined high-impact action.
- Expiration behavior: when the permission ends and which queued work it covers.
For retrieval, issue read-only credentials and enforce tenant-aware predicates inside the vector query. Don't grant database-wide read access when a read replica or a small set of tables is sufficient. Explicitly exclude arbitrary shell execution and unrestricted HTTP requests unless there is a narrowly bounded, separately governed use case.
Handle exceptional mutations
Writes, deletion, external messages, financial transactions, and cross-system changes deserve a dry-run diff. Show the exact records, fields, recipients, or downstream effects before execution, then require approval sized to the blast radius.
Use just-in-time elevation for an exceptional operation. The elevated permission should be issued for the specific task, resource, and action, then revoked automatically after completion or failure. An inherited OAuth grant or cached credential should never become a permanent shortcut.
Test the matrix as a frozen contract
Authentication isn't authorization. A valid agent identity may still lack permission to read a particular tenant or invoke a particular operation.
Build a frozen allow/deny test set containing permitted and adversarial combinations. The operational target is 100% denial of unauthorized tool, resource, and operation combinations, zero cross-tenant reads in adversarial tests, and complete audit coverage for every privileged action, as specified in the AWS and OWASP-oriented guidance on agentic AI authorization testing. Any failure is a release blocker, not a result to average away with successful requests.
Required audit fields include identity, tool, resource, scope, decision, approval, outcome, tenant, task context, and the policy version used. Test asynchronous jobs separately because a correct foreground decision doesn't automatically authorize a later worker execution.
Designing Approval UX That Actually Preserves Intent
Human approval sounds like a strong final gate until the interface turns every request into a routine click. A reported study found that reviewers caught approximately 17% of dangerous commands early in a session, while detection fell to about 5% after 50 or more prior prompts, according to the evidence summarized in the analysis of least-privilege AI agents. The same source reports that humans approved 97% of presented requests, which can indicate habituation rather than sound judgment.
The lesson isn't to remove people from high-impact decisions. It's to stop treating approval frequency as a safety metric.
Present an operation, not a vague question
An approval request should expose the exact proposed arguments, affected resources, tenant, identity, policy result, and reversible dry-run outcome. “Allow the agent to continue?” gives the reviewer no useful basis for deciding whether the action matches intent.
Approval should apply to a narrowly defined action. A user approving an email reply shouldn't automatically authorize a CRM update, a data export, or a financial transaction created later by the same task.
A layered flow works better:
- Constrain tools and credentials before the agent proposes anything.
- Classify the action by impact and reversibility.
- Require approval only for defined high-risk operations.
- Show arguments, scope, affected resources, and the dry-run result.
- Re-enforce the same policy server-side after approval.
The final server-side check matters because approval is evidence of a human decision, not a replacement for authorization. Resource state may have changed between the approval screen and execution.
Measure comprehension and degradation
Seed unsafe actions into controlled evaluations and calculate dangerous-action catch rate, unsafe-approval rate, false denials, median review time, and degradation by prompt or session length. Also measure whether the final action stayed within the user's stated constraints.
A 2026 literature survey of 21 agent-permission systems from 2024–2026 found that the field clusters around reducing user overhead, formalizing security principles, and deterministic enforcement, showing that human-centered permission decisions remain an emerging area rather than a settled practice. See the survey of agent permission systems for its scope and limitations.
More prompts can reduce safety when they are repetitive, vague, or shown after the agent has accumulated broad context. When the user's intent contains an unresolved dimension, the system should abstain and identify the missing constraint, rather than ask for a generic approval that the reviewer can't meaningfully evaluate.
Revocation and Incident Response for AI Agents
Least privilege limits damage, but it doesn't tell the team how to stop a live agent. Resetting a human password may leave service accounts, API keys, workload identities, OAuth grants, borrowed sessions, memory references, and queued jobs active.
The incident runbook must follow the capability chain, not just the visible application. Start by freezing new work and identifying every delegated capability associated with the agent task. Preserve the principal, represented user or organization, tenant, scope, and task context at every delegation hop so investigators can distinguish an intended call from a confused deputy.
Stop the authority chain
A practical sequence is:
- Deny new requests for the agent identity at the policy layer.
- Revoke task-scoped grants and invalidate downstream tokens, API keys, OAuth grants, and workload credentials.
- Block queued asynchronous jobs that have not started.
- Inspect already-authorized jobs separately, because a queued mutation may have received approval before the incident.
- Disable memory and retrieval references that could continue exposing sensitive context.
- Preserve tamper-resistant logs for requests, decisions, approvals, executions, and failures.
- Identify affected tenants and resources before remediation or notification decisions.
The difficult question is operational: how quickly can the team identify and withdraw every delegated capability? Define objectives for time-to-discovery, time-to-denial, token-chain completeness, and treatment of already-authorized asynchronous jobs. Measure those during exercises, not only after an incident.
Design identity for withdrawal
Recent standards work is moving toward agent-specific identities linked to both the software and the represented human or organization, with authorization provisioned dynamically when needed and curtailed automatically after task completion, as described in this AI agent incident response runbook. That direction addresses a practical weakness in models that rely on long-lived, opaque service credentials.
Every delegation hop should preserve:
- Principal: the agent and represented user or organization.
- Scope: the exact resources and operations.
- Tenant: the boundary that must never be inferred from model text.
- Task: the job that justified the grant.
- Expiry: when the authority ends.
- Status: whether queued and in-flight actions remain valid.
Teams also need observability that can correlate a model proposal with a policy decision and the final downstream effect. Agentic AI observability is useful only when it exposes those control relationships, not merely latency and token counts.
Mapping Controls to the EU AI Act Timeline
The EU AI Act turns access control into a lifecycle obligation for certain high-risk systems. The Act entered into force on 1 August 2024, prohibited practices began applying on 2 February 2025, and general-purpose AI obligations followed on 2 August 2025. High-risk Annex III obligations are scheduled from 2 December 2027, while high-risk AI integrated into regulated products is scheduled from 2 August 2028, according to the European Commission AI regulatory framework.
For systems used in areas such as biometrics, critical infrastructure, education, employment, migration, border control, and access to essential services, providers must address conformity assessment and requirements covering risk management, data quality, logging, documentation, traceability, transparency, human oversight, accuracy, cybersecurity, and resilience.
A design review should ask:
- Is every agent and delegated user identity explicit?
- Does policy resolve from trusted state rather than model output?
- Does retrieval enforce tenant and document permissions before context assembly?
- Do downstream services re-check authorization?
- Are logs automatic, complete, and tamper-resistant?
- Are technical documentation, registration, incident reporting, corrective action, and remediation owned by named teams?
- Does execution fail closed when authority or provenance is missing?
This is also where MR2 Solutions on compliance in IT security can provide broader governance context. The engineering takeaway is direct: authorization, provenance, fail-closed behavior, and auditable state map to measurable compliance controls, not just internal security preferences.
AletheionAGI provides grounding and evidence-control infrastructure that can work with existing LLMs, RAG pipelines, vector databases, and memory systems, applying authorized retrieval and fail-closed context delivery rather than replacing those components. If you're designing authority-before-autonomy for sensitive or multi-tenant AI, visit AletheionAGI to explore its API-based controls and evidence-bounded architecture.
