AI agents change the security question from “what did the model say?” to “what was the system allowed to do?” Once an agent can call tools, access records or trigger workflows, its identity and authority become part of the security boundary.
NIST is treating agent identity as infrastructure
In 2026, NIST’s Center for AI Standards and Innovation published work on security considerations for AI agents and a concept paper on identity and authorization for software agents. The direction is significant: agent security is not only about model behaviour or prompt injection. It is also about connecting a delegated action to a real user, a defined purpose and an auditable permission.
That is more useful than treating an agent as an unusually clever service account. A service account with broad access is already difficult to govern. An agent adds planning, interpretation and tool selection, increasing the ways a legitimate instruction can produce an unsafe result.
Delegation needs a boundary
An agent should not inherit every permission available to the person who started it. Delegation should be explicit and narrow: which user initiated the task, which agent is acting, which tools are available, which resources are in scope, how long authority lasts and what actions require confirmation.
If an agent calls a second agent or an external service, downstream action should not lose the original context. Systems need to preserve the relationship between the human request, agent plan, tool call, result and final action.
Logs must explain actions, not just errors
Many systems log authentication and application errors but not the decision path that matters most. An agent audit record should show the triggering request, relevant policy, tools considered, tool called, data returned, approval checkpoint and resulting change.
This does not mean storing every internal model token. It means enough structured evidence to reconstruct responsibility. A reviewer should tell whether the agent acted within authority, whether a human approved the right step and whether the system had enough information to make the action safe.
Least privilege is necessary but not sufficient
An agent that only needs to read a ticket should not be able to close it, change an entitlement or export a customer list. But permissions alone do not solve context confusion. A read permission can expose sensitive information, and a valid write permission can still be inappropriate for a particular case.
Controls should combine permissions with purpose, data classification, transaction limits and separation of duties. High-impact actions may need a second person, restricted workflow or reversible staging step. The control should depend on the consequence of failure, not whether the interface says “assistant” or “agent”.
Make the failure path part of the design
Agent systems encounter ambiguous instructions, malicious content, unavailable tools and conflicting records. A safe design makes refusal and escalation normal outcomes. The agent should stop, explain what is missing and route the task to an owner without trying increasingly broad actions.
Testing should include indirect instructions in retrieved documents, poisoned tool responses, stale permissions, duplicate requests, partial failures and attempts to cross a data boundary. NIST’s work points toward shared standards, but each organisation still has to test the concrete agent and workflow it operates.
What teams can implement now
- Give each production agent a distinct identity and owner.
- Record the human principal, purpose and expiry for delegated work.
- Use narrowly scoped tools with separate read and write permissions.
- Require confirmation or second-party approval for consequential actions.
- Log tool calls, approvals, data boundaries and resulting changes.
- Review dormant agents and revoke access when ownership changes.
The shift is from model trust to action accountability
Capability is not authority. The safer pattern is to treat an agent as a delegated operator whose identity, permissions and actions remain visible throughout the workflow. That gives organisations a practical basis for trust: not confidence that the agent will always behave well, but evidence that failures can be bounded, detected and corrected.