Consider an AI agent that can investigate a production incident and reset a compromised account. Its distinct workload identity supports attribution; short-lived credentials and scoped access limit how far it can reach. None of those controls determines whether it may reset this account now.
A valid reset may require an active incident that names the account, evidence that meets policy, and approval from the incident commander. Without those conditions, a perfectly authenticated agent can still make an unauthorized change at 2 a.m.
Identity establishes who is acting, while authority defines what that actor may recommend, approve, execute, delegate, or stop under the conditions of this incident. A production review needs both.
NIST’s National Cybersecurity Center of Excellence closed public comments on a software and AI agent identity and authorization concept paper on April 2, 2026. The paper asks how established identity practices apply to agents and treats authorization, auditing, non-repudiation, and prompt injection as related but distinct concerns.
Identity Establishes The Actor
A production agent shouldn’t borrow a developer’s credentials, share an account with unrelated automations, or inherit every permission held by its host application. Give it a distinct, non-human identity tied to one operational role. That identity lets the organization issue and rotate credentials, assign base permissions, log requests, and revoke access.
Authentication proves only where a request came from. It doesn’t prove that current evidence supports an account reset, that the account falls within the containment scope, or that the required approval exists. Traditional access control asks whether a principal can call an API. The workflow must also decide whether that call is permitted now.
Authority Lives In The Decision
A role such as security-assistant can grant base access. The workflow must connect evidence, policy, approval authority, execution, recovery, and observable outcomes to decide whether a particular action is authorized under current conditions. Evodant calls the engineering of that path Decision Engineering.
An incident ticket alone isn’t enough when the evidence is stale, the account sits outside the approved containment plan, or the reset would interrupt a business service. Express the authority in terms the security team can test:
This agent may reset account X during incident Y when the required evidence is current, the action falls within the approved containment plan, and the incident commander has authorized any exception.
A generic account-reset permission omits those operating conditions.
Match Authority To Consequence
Least privilege applies to the kind of authority an agent holds, not only the systems it can reach. Choose the automation level according to the consequence of the action:
| Authority Level | What The Agent May Do | Required Control |
|---|---|---|
| Decision support | Organize evidence and present options | An authorized person interprets the evidence and decides |
| Decision augmentation | Produce a bounded recommendation | An authorized person approves, changes, or rejects it |
| Bounded automation | Execute a defined, recoverable action when policy conditions are met | Policy limits execution; a named owner monitors outcomes and can suspend it |
Bounded automation must stop and route the decision to an authorized person when evidence, policy, or authority falls outside its boundary. Use decision support or augmentation until representative operating evidence supports execution.
Bound The Damage When The Model Fails
Agents may read email, tickets, documents, websites, and repositories. An attacker can place instructions inside that material to redirect the agent, a technique called agent hijacking or indirect prompt injection.
On March 23, 2026, NIST published an analysis of a large AI agent red-teaming competition. More than 400 participants made over 250,000 attack attempts against 13 frontier models. At least one attack succeeded against each target model, and some attack families transferred across models and scenarios.
The competition tested models, not complete production workflows. Prompt defenses and model testing therefore can’t carry the full security burden. Tool scopes, action-specific authorization, informed approval, monitoring, and revocation must constrain what follows a bad model decision. Broad execution rights can turn a model weakness into a production change.
Make Delegation And Recovery Explicit
An agent may act under its own operational role or on behalf of a person. When someone delegates a task, bind that authority to a purpose, allowed actions, resource scope, and expiration. The agent shouldn’t inherit every permission held by the user or keep acting after the business context has expired.
If one agent asks another to retrieve evidence or execute a step, the receiving agent needs verifiable delegation context. That context should identify the originating principal, permitted action, resource scope, expiration, and whether further delegation is allowed. Valid identities at each handoff can’t legitimize an action that exceeds the original scope.
Plan revocation and recovery before deployment such that operators need a direct way to suspend the agent, remove a tool permission, invalidate a delegation, and stop one workflow without disabling unrelated services. For every executable action, document how operators will detect failure, contain its effect, reverse it where possible, and reconstruct the decision.
Require An Inspectable Record
Before production approval, create one record for the agent and its workflow. It should answer five questions:
- What operational purpose does the agent serve, and who owns the outcome?
- Which identity does it use, and how can operators revoke it?
- Which evidence, tools, resources, and environments may it reach?
- Which decisions may it support, and which actions may it recommend or execute, under which policy and approval conditions?
- How will operators stop execution, recover, and inspect what happened?
Tie the record to the deployed workflow version. A changed model, tool, evidence source, permission, or approval rule can alter the decision boundary and should trigger review.
Start with one consequential action, then test routine cases along with stale evidence, hostile instructions, expired delegation, and failed approvals. Expand the authority only when the observed behavior supports it.
Setting an agent’s authority before production? Book a Consultation.