How should enterprises authorize AI agents to take operational action?
Give each agent a verifiable workload identity, but authorize each consequential action through a separate task-scoped grant. Enforce resource, action, tool, context, approval and revocation rules at the execution boundary; narrow delegated authority across agent hops; and link the request, decision, execution and verified outcome in an evidence chain.
Why identity is necessary but insufficient
In February 2026, the US National Institute of Standards and Technology's National Cybersecurity Center of Excellence published an agentic identity and authorization concept paper. Its current summary reports more than 600 responses. That figure shows substantial stakeholder participation; it is not an incident count, a deployment count or a representative survey of enterprises.
The synthesis describes three broad deployment models: an enterprise-controlled internal agent, an enterprise-owned agent exposed to outside users, and an externally owned agent interacting with enterprise resources. Control over identity and infrastructure differs across those boundaries, so the same trust assumptions cannot simply be copied from one model to another.
A verifiable workload identity can establish which service or agent instance is calling. Authorization answers a different question: may this caller perform this operation on this resource, for this task, under these conditions, right now? An enterprise needs both answers before execution.
Five distinctions that should survive architecture review
These are Ariftly engineering inferences informed by the primary sources, not a single normative standard. They are useful because each one identifies a place where an apparently valid identity or credential can still leave an action unauthorized, unattributable or impossible to stop.
- Identity is not authority: authenticating a workload does not grant it every action it can describe or invoke.
- A sponsoring principal is not the agent identity: keep the accountable owner, calling workload and grant distinguishable.
- An executable tool is not a permitted tool call: technical discoverability is not authorization.
- Approval is not indefinite authority: bind approval to a specific action, resource, constraints and request digest.
- Expiration is not immediate revocation: test how current revocation state reaches every enforcement point.
A synthetic modernization example
Consider a fictional Oracle-to-Snowflake assessment using only synthetic inputs. A workflow owner sponsors project T-17. An assessment agent may read the project's SQL and prepare a translation plan. A validator may run read-only checks in an isolated environment. Neither workload receives production write access by implication.
A model may propose dropping a production schema as a cleanup step. The authorization boundary must deny the operation because the resource, action and environment fall outside the grant. The same result applies when a validator receives a broad instruction to finish the job: an agent-to-agent handoff cannot create new authority.
This example is a design fixture, not a product demonstration or customer deployment. It deliberately separates capability from permission and gives the negative path equal importance to the allowed path.
| Hop | Identity | Requested action | Boundary | Result |
|---|---|---|---|---|
| 0 | Workflow owner | Sponsor assessment | Synthetic project T-17 | Baseline scope |
| 1 | Assessment agent | Read SQL and propose translation | T-17 inputs; 20 min illustrative expiry | Allow with evidence |
| 2 | Validator agent | Run read-only checks | T-17 isolated staging; child scope | Allow if parent is valid |
| 3 | Validator agent | Drop production schema | Production database | Deny: no resource or action right |
Delegated authority must narrow across agent hops
Agent-to-agent handoffs can hide attribution unless every child grant retains its parent reference and a deterministic scope comparison. Ariftly's proposed invariant is simple: a child grant may be no more permissive than the valid authority available to its delegator for the same task. Any expansion requires a fresh accountable grant.
OAuth 2.0 Token Exchange, RFC 8693, defines token exchange and distinguishes delegation from impersonation semantics. Rich Authorization Requests in RFC 9396 can represent finer-grained authorization details. These standards supply useful protocol pieces; they do not decide the enterprise's resource semantics, approval rules or permitted delegation depth.
A downstream service should be able to establish who the agent is and why this particular authority exists. An agent name, parent-written instruction or copied user credential is not a sufficient delegation record.
Keep permission outside probabilistic reasoning
NIST's consultation summary records very strong opposition to using language models or other probabilistic mechanisms as the primary or sole authorization arbiter. Respondents still saw value in probabilistic signals for anomaly detection and contextual analysis, but the synthesis points to deterministic policy and enforcement as essential.
A practical execution path is: untrusted request → authenticated agent identity → current task and grant → deterministic policy decision → specific approval when required → enforced tool call → independently checked result → linked evidence. The model can recommend an action; it cannot authorize itself.
This separation is especially important under prompt injection. Text retrieved from a document or tool is input to the workflow, not a policy update. The enforcement point must block an operation even when the model confidently describes it as necessary.
Tokens support the boundary; they do not define it
RFC 9068 defines a JWT profile for OAuth access tokens, RFC 9449 defines sender-constrained tokens using Demonstrating Proof of Possession, and RFC 9700 records current OAuth security best practice. These mechanisms can strengthen validation, audience restriction and token handling. They do not turn an ambiguous task into a precise authorization policy.
Short-lived credentials bound future exposure, but expiry alone does not prove immediate revocation across resource servers or stop an in-flight action. Define the revocation event, acceptable propagation behavior, session cancellation and downstream response, then test them in the actual environment before publishing any latency claim.
Evidence must connect authorization to outcome
An API success response is not an authorization record and does not prove that the intended workflow outcome occurred. At minimum, link the request identity, sponsor, task, resource and operation, policy version, decision, applicable approval, tool execution, verification result and exception owner.
For a denied request, preserve a stable reason code and resolution owner. For an approved consequential request, bind approval to a digest or normalized representation of the action rather than an unstructured statement that someone said yes. For multi-agent work, keep enough identifiers to reconstruct the delegation chain without copying full prompts, secrets or personal data into a universal log store.
Privacy minimization, retention, integrity and incident access remain separate requirements. More logging is not automatically better evidence if the record is indiscriminate, unprotected or impossible to interpret.
Measure design completeness without claiming security effectiveness
For each applicable matrix field, record whether a reviewable specification and evidence location exist. Design completeness equals 100 multiplied by verified applicable fields divided by all applicable fields. With twelve applicable fields and nine verified specifications, the fictional result is 75%.
That number means only that three design fields are missing. It does not mean the agent is 75% secure, that controls are 75% effective or that an audit will pass. Identity trust, resource and action boundaries, delegation validity and revocation state remain blocking conditions regardless of the average.
| Fixture | Applicable fields | Verified fields | Completeness | Interpretation |
|---|---|---|---|---|
| Synthetic grant alpha | 12 | 9 | 75% | Design inventory only; not a security score |
| Synthetic grant beta | 12 | 12 | 100% | All fields specified; enforcement still unproven |
Test denials, revocation and changed approvals
Before claiming enforceability, run negative tests for an unknown identity, forbidden tenant, disallowed write, expanded subagent scope, stale grant, changed approval payload, revoked credential and malicious instructions embedded in tool output. A test passes only when both the operation and the evidence record behave as specified.
Failed tests are findings, not inconvenient cases to remove from a rate. Any operating assurance claim needs the threat model, environment, denominators, failures and implementation details. The downloadable package provides synthetic fixtures and expected decisions, not measured production results.
Ariftly View: from human-operated to AI-operated
Ariftly starts with the workflow rather than the model. Human-operated work often contains implicit approvals, shared privileges and repeated exception handling. AI assistance can prepare actions while a person still operates the system. Bounded execution adds narrow grants, deterministic tool checks and explicit exception routes for selected low-risk steps.
More AI-operated work should expand only where measured reliability, revocation, recovery and review arrangements support the added authority. The goal is not to erase people or accountability. It is to reduce repetitive interpretation, prepare exceptions faster, prevent false-success states and preserve human attention for consequential decisions.
Autonomy and authority remain separate axes: a technically capable agent may still receive very little authority, while a deterministic operation may receive broader permission because its boundaries and failure handling are well understood.
How Ariftly would operationalize this workflow
Within Ariftly's in-development Forge direction—Record, Redesign, Operate—a forward-deployed engagement would first record who performs actions, which systems are touched and where exceptions occur. Redesign would make authority and approval boundaries explicit, separate probabilistic interpretation from deterministic enforcement, and define the evidence needed at each decision. Operate would connect permitted actions to checks, exception owners and reviewed changes.
Forward-Deployed AI Engineering is the implementation motion around one bounded workflow. Forge, Engine and Runtime remain developing directions; the matrix is not a claim of a shipped authorization product or customer deployment. Oracle SQL to Snowflake is the concrete local V1 and has been tested only with synthetic inputs.
Methodology, limitations and citation
This article synthesizes NIST NCCoE's 2026 consultation summary, NIST zero-trust guidance, five published OAuth RFCs and the living SPIFFE specifications. Primary URLs and the central claims were rechecked on 21 October 2026. NIST's comments document is a qualitative synthesis; it does not measure incident prevalence or prove that a particular architecture is secure.
The twelve fields, narrowing invariant, evidence record and test fixtures are Ariftly-authored proposals. They have not been independently validated as a universal minimum and do not substitute for architecture-specific threat modeling, security testing, privacy review or applicable legal requirements.
Suggested citation: Ariftly (2026), Ariftly Agent Authority Matrix, v1.0. The original framework, schema and synthetic fixtures are available under CC BY 4.0. Third-party standards and source documents retain their own terms.