The runtime access triad is a governance model that separates what an AI agent may access, what it may do and what it may expose. It is useful because agentic systems often cross those boundaries in one task, which makes single-step authorisation too coarse.
What the Runtime Access Triad Means
The runtime access triad is best understood as a governance split inside agent permissioning: access defines the resources in scope, action defines the operations allowed, and exposure defines what the agent may reveal or return. That separation matters because a single task can require all three decisions, but not at the same privilege level.
In practice, the model prevents a common design error, treating “may use” as the same as “may disclose.” An agent can be allowed to read a record, update a record, or summarise it outward, but those are distinct authorisation choices with different blast radii.
Why the Triad Exists
Agentic systems are different from ordinary applications because a runtime request often chains multiple steps across tools, data sources and outputs. Without a triad, teams often collapse those decisions into one broad grant, which makes policy too coarse for the real task.
The triad is therefore a governance model for separating capability from disclosure. It helps designers ask whether a model needs direct access to an object, permission to mutate it, or permission to expose it in a response, log, or downstream tool call.
How Access, Action and Exposure Differ
Access is about whether the agent can reach a resource at runtime. Action is about what it can do once it reaches that resource, such as read, write, invoke, approve, or delete. Exposure is about what can leave the boundary of the task, especially when an agent can transform private inputs into a public or wider-scope output.
That distinction becomes especially important in agentic workflows that combine retrieval, tool use, and response generation. The same identity can need narrow read access, even narrower write authority, and a separate disclosure policy for the content it is allowed to surface.
- Access answers, “Can the agent touch this system or dataset?”
- Action answers, “What can the agent do with it?”
- Exposure answers, “What can the agent reveal outside the controlled context?”
Where the Triad Is Most Useful
The triad is most useful where a single agent session can span multiple trust boundaries, such as internal knowledge bases, ticketing systems, databases, and external outputs. It also helps when different steps in the same workflow have different sensitivity, for example reading a confidential field, updating a workflow state, and producing a user-facing summary.
One useful reference point for the underlying runtime boundary problem is NIST SP 800-190 Container Security, because it treats image, registry, orchestrator and runtime exposure as separate concerns that must each be controlled. For access scoping in machine-to-machine flows, RFC 8707: Resource Indicators for OAuth 2.0 is also relevant because audience restriction is a concrete way to keep runtime access tied to the intended resource.
Risk and Threat Considerations
The main risk is overbroad runtime authority, where access, action and exposure are granted together even though only one of them is truly needed. That creates a larger blast radius if the agent is misused, prompted into the wrong behaviour, or fed malicious instructions through a tool or context source.
Failure mechanism: When policy does not separate the three decisions, an agent can read more than it should, act more broadly than intended, or leak more than the workflow allows, turning a narrow task into a privilege and disclosure problem.
Impact: The result can be unauthorized modification, sensitive data exposure, cross-boundary tool misuse, or escalation from a harmless assistant action into an operational security incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The triad separates access, action, and exposure to limit agent privileges by task need. |
| AC-4 — Information Flow Enforcement | Exposure is an information-flow decision about what the agent may reveal or route onward. | |
| IA-5 — Authenticator Management | Runtime access governance depends on controlling the credentials and tokens that enable agent actions. | |
| Recommendation — Apply AC-6 to constrain each agent step to the minimum access, action, and disclosure required. Use AC-4 to enforce separate rules for what an agent may disclose, transmit, or return. Use IA-5 to manage and rotate the credentials that authorize agent runtime access. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The triad is designed to prevent agent identity from collapsing into broad privilege at runtime. |
| ASI02 — Tool Misuse | Separating action from access reduces the chance that a tool-capable agent overuses its runtime tools. | |
| ASI09 — Human-Agent Trust Exploitation | Exposure controls matter because trust in agent output can cause unsafe disclosure or action. | |
| Recommendation — Constrain agent identities so access, action, and disclosure remain separately authorized. Restrict tool invocation to the smallest action scope needed for the task. Review outputs for over-disclosure and prevent trust from bypassing runtime policy. | ||
Practitioner Guidance
Why practitioners should care: The triad is a useful way to make agent permissions auditable instead of implicit. It forces teams to define what the agent may reach, what it may change, and what it may disclose as separate governance decisions rather than one vague allowance.
Common misunderstanding: Teams often assume that a read permission is harmless if write permission is denied. In agentic systems, read access can still create exposure if the agent can summarise, transform, forward, or combine the information in a way that breaks the intended boundary.
Practitioner takeaway: Treat runtime policy as three controls that must all be justified independently, especially when the agent moves between internal data, tools, and user-facing output.