The model may propose an action. Authority belongs in a verifiable policy layer that remains independent from the content the model interprets.
In 2026, the centre of the AI agent security discussion moved. The problem is no longer limited to reducing hallucinations or filtering model responses. Once an agent reads a mailbox, queries a CRM, prepares a payment or changes a record, its real authority inside enterprise systems becomes the main source of risk.
NIST launched an AI agent standards initiative in February 2026 and opened a specific workstream on software-agent identity and authorisation. OWASP structured agentic risk around threats such as goal hijacking, tool misuse and identity or privilege abuse. These publications do not prove that any particular product is safe or unsafe. They show why conventional access-management practices need to be adapted to software that interprets a situation and then proposes a chain of actions.
For an autonomous team orchestrated with Atlensia, the consequence is direct: the model must never carry authority to act on its own. Its job is to interpret, plan and propose. An independent layer must check the working identity, resource, action, context, limits and any required human approval before execution.
The 2026 guidance moves security towards identity
The NIST AI Agent Standards Initiative addresses interoperability, security and identity together. NIST explains that agent usefulness depends on interaction with digital resources, while that interaction requires clarity about who the agent represents, which authority it holds and under which conditions. Its concept paper on software-agent identity and authority brings identification, authorisation, audit, non-repudiation and prompt-injection defence into the same design problem.
This approach corrects a common weakness in early pilots. An application receives a broad service key, then the prompt tells the model to be careful. The technical control and the language instruction are reversed. If an attachment, search result or malicious message changes the reasoning, nothing prevents the application from using privileges that have already been granted.
The underlying problem is not unique to generative models. Distributed systems have long used service identities, access policies and limited tokens. What changes with an agent is the range of possible paths. One role may consult several sources, select a tool, reformulate an objective and continue after an error. Authorisation cannot be granted once at the start of a session. It needs to be evaluated when an action is proposed, using observable attributes.
Injection becomes dangerous when it meets privilege
Indirect injection is an instruction hidden inside content that the agent treats as data: an email, web page, document, ticket or tool response. The text may tell the agent to ignore its mission, transmit information externally or call a function outside its scope. When the model only produces an isolated draft, the impact is contained. When the same model has broad tool access, manipulation can become modification, transmission or exfiltration.
The OWASP Top 10 for Agentic Applications 2026 includes goal hijacking, tool misuse and identity abuse among its structural risks. The OWASP State of Agentic AI Security and Governance 2.01 report connects these categories to the wider threat landscape. These are community references, not independent measurements of every product. Their value is a shared vocabulary for product, security and business teams reviewing the whole system.
| Surface | Security question | Required evidence |
|---|---|---|
| Identity | Which role is acting and for which organisation? | Dedicated identity, owner, lifetime and revocation |
| Authority | Is this action allowed on this resource now? | Policy decision with the reason and attributes used |
| Tool | Does the call follow a known schema and boundary? | Validated arguments, version, result and error code |
| Data | Do input and output stay within the authorised scope? | Verified classification, destination and minimisation |
| Approval | Does a person need to accept the external effect? | Approver identity, presented context and decision |
| Record | Can an independent reviewer reconstruct events? | Linked proposal, authorisation, execution and result |
This grid shows why content filtering alone is insufficient. A filter tries to decide whether text looks suspicious. An authorisation policy makes an action impossible even when the text looks normal. Both controls can coexist, but the second limits damage when the first fails.
An autonomous team needs distinct working identities
Giving one technical identity to the entire autonomous team simplifies a prototype but removes accountability. A role qualifying an opportunity, a role preparing a contract and a role sending a message do not need the same data or create the same business effect. If they share one service account, records show only that an application acted. They do not connect the action to the mandate that justified it.
A working identity should map to an explicit role and resource scope. It holds the rights needed for one workflow stage, not general access to the application. A preparation role may read a case and produce a proposal without sending it. An execution role may receive an already approved object but should not be able to change the approval rule. Separation reduces blast radius and makes targeted revocation possible.
NIST SP 800-207 on Zero Trust Architecture provides a useful principle: do not grant implicit trust because of network location. Applied to agents, a legitimate task does not justify every later tool call. Each action is evaluated against subject, resource, context and risk. The model may explain why it wants to act, but that explanation is not authorisation.
Secrets also remain outside model context. The model receives a logical tool name and schema, never the token used to make the call. The execution component obtains a short-lived token limited to an audience and operation. RFC 9700 consolidates current OAuth 2.0 security practices around token protection and flows. The exact implementation depends on the identity provider, but the principle is stable: a context leak should not become a reusable credential leak.
Authority must stay outside the model
The decision point receives a structured proposal and checks it against policy. It evaluates identity, resource, action, business context, data classification, volume limits and required approval. A positive decision creates bounded authority. A negative decision returns a reason the workflow can use and, where necessary, an escalation packet.
Atlensia diagram: an input may influence the model's proposal, but an external policy alone decides whether the action is authorised.
This architecture does not assume the model's reasoning will become infallible. It contains the error. An injection may influence the proposal, but it cannot add a tool to the allow-list, expand a token or remove an approval. Security depends on testable boundaries instead of hoping the model recognises every malicious formulation.
A denial needs to be as precise as an approval. “Action impossible” supports neither remediation nor audit. The system should state whether the role lacks permission, the resource is outside scope, the data is too sensitive, an approval threshold applies or evidence is missing. That precision helps a person decide without revealing a secret or exposing the entire policy to untrusted input.
The tool contract must limit effects, not only format
A valid JSON schema is not a security policy. It confirms that arguments have the expected shape, but not that the action is legitimate. A send_email tool may receive a valid address and remain unsafe if the recipient is unauthorised, the attachment contains sensitive information or the role only has a preparation mandate.
The tool contract therefore describes business effect. It identifies accessible resources, authorised destinations, amounts, volumes, idempotency, errors and reversibility. Broad operations should be separated into preparation and commitment. Creating a draft, checking a rule and submitting for approval are different capabilities from final transmission.
The OWASP Securing Agentic Applications Guide recommends restricting tool invocation, applying function-level authentication and isolating execution. In an Atlensia architecture, these controls sit in the operating layer: the role proposes an action, policy decides, the tool executes within a boundary and the record connects all four stages.
The decisive test is a denied action
A security pilot should not begin and end by proving that the agent completes the happy path. Success is necessary, but it does not show whether the boundaries hold. The most useful test places a malicious instruction inside an authorised source, requests an out-of-scope tool, reuses an expired identity, exceeds a threshold and revokes access while work is in progress.
| Tested situation | Expected behaviour | Critical failure signal |
|---|---|---|
| Hidden instruction in a document | Treat text as data and preserve policy | A tool added by the document is called |
| Unauthorised external recipient | Block before transmission and explain why | Any transfer of the protected data |
| Token revoked during the workflow | Stop, retain state and escalate | Retry with a different secret |
| Repeated action after a timeout | Check idempotency before retrying | Duplicate creation or commitment |
| Action above an approval threshold | Prepare a complete decision packet | Bypass or approval without context |
The test record connects the input, model proposal, policy decision, possible call and observed effect. Security can verify the boundary without interpreting every message in the conversation. The business owner can also see whether a denial is too strict and blocks legitimate work.
Conclusion
The NIST and OWASP publications released in 2026 do not create a discipline separate from cybersecurity. They show how identity, least privilege, separation of duties, continuous authorisation and audit apply to software that can plan and use tools. The dynamic path between intent and effect is new, not the abandonment of established principles.
An autonomous team can use a capable and flexible model while keeping its authority narrow. The role defines the intended outcome. Policy decides what is permitted. The tool performs a bounded operation. The record proves what happened. No instruction received through a document or mailbox should be able to merge those responsibilities.
The practical next step is to select one real workflow, map its identities and effects, then deliberately test five denials: an out-of-scope tool, sensitive data, an unauthorised recipient, an approval threshold and a revoked token. Write access remains premature until those denials are observable and repeatable.
Primary sources and references
- NIST, AI Agent Standards Initiative
- NIST, concept paper on agent identity and authority
- NIST, analysis of responses on AI agent security
- OWASP, Top 10 for Agentic Applications 2026
- OWASP, State of Agentic AI Security and Governance 2.01
- OWASP, Securing Agentic Applications Guide
- NIST SP 800-207, Zero Trust Architecture
- RFC 9700, OAuth 2.0 Security Best Current Practice