Your AI Agent Has a Login. That Is Not the Same as Control.
Microsoft's 2026 Digital Defense Report landed on October 1 with a useful reminder: AI agents are not isolated models. They reach into enterprise data, applications, APIs and tools. Microsoft calls out agent identity, access, attribution and revocation alongside prompt injection and memory risk. The important word is alongside. A perfect model evaluation cannot tell you whether an agent can quietly use a valid token to export a client file.
Security teams should resist treating agent governance as a new checkbox in the identity console. A named account answers who authenticated. It does not answer why a particular action was allowed, what data the agent saw, or how to stop the next step when its instructions change.
The ordinary workflow is the test
Imagine a procurement agent that reads a supplier email, finds a contract in a document store and drafts a reply. It needs a mailbox, search permission and perhaps a CRM connection. Each is defensible in isolation. Now the email contains a sentence asking the agent to attach the full contract and send it to a different address. The sender's text is task data, not an authorized instruction. If the agent can use a broad mailbox token and document-store access without a separate decision at the point of action, its named identity has done little to contain the mistake.
This is not a claim that the Microsoft report documents that exact incident. It is a practical test case drawn from the system boundaries the report describes. The question for a CISO is whether the same credential that lets the agent read also lets it disclose, modify or delete, and whether anyone can reconstruct the sequence afterward.
An AI agent execution policyshould specify permitted actions at each boundary, not merely list the agent as approved. Before rollout, ask the owner to walk through one routine workflow et one poisoned-input workflow, with actual permissions et logs in view.
The gap between identity et authority
A dedicated agent identity is better than a shared employee login. It makes ownership et revocation possible. But three gaps remain.
First, scope can still be too broad. A token that can read an entire drive is not made safer because its principal is called `procurement-agent`. Narrow it to the folders and operations the task requires. Separate reading from sending or changing records. Make higher-impact actions require a distinct grant, not a convenient inherited role.
Second, the instruction source matters. An agent will encounter text in email, retrieved pages, tickets and documents. None of these should become a fresh authority to change recipients, move money or adjust access. Put an action check between the model's proposed step and the underlying API. The check should use a trusted workflow definition, destination allowlist and data classification, not the model's own explanation of why the action is safe.
Third, a valid token may outlive a valid task. Limit its lifetime, rotate it, and ensure the team can revoke it without disabling an employee's entire account. An agent with a forgotten persistent credential is a standing access path, even while nobody is watching the workflow. Microsoft explicitly identifies the ability to revoke agent access as part of the security picture; do not bury it in an incident runbook nobody has tested.
What to put in the control record
For each production agent, keep one short record that a security reviewer can actually use:
- A human owner et business purpose, with a date for review.
- The identities, connected systems et exact read, write et send permissions.
- The data classes it can ingest et the destinations it can reach.
- The actions it may take alone, the actions needing human approval et the actions it cannot take.
- Token issuer, lifetime, revocation path et a tested emergency stop.
- Logs that join the input source, proposed action, policy decision et resulting API call under one task ID.
This is not bureaucracy for its own sake. In an incident, an identity log might show that a token was used successfully. The joined action trail should show which email or retrieved document preceded the request, whether the destination changed, what the policy decided and whether any data actually left. Without that trail, investigators can prove access but not explain behavior.
Do not start with every prototype in the company. Start with agents that can send externally, change permissions, edit production records or access regulated data. These are the workflows where the difference between a useful assistant and an unauthorized operator becomes expensive. For a lower-risk drafting assistant, a read-only connection and a human copy-and-paste step might be enough. Controls should match consequences, not fashionable labels.
Test the stop, not just the start
A rollout review often ends when the agent completes the happy path. Run a second exercise: insert an untrusted instruction into a document the agent will retrieve. Ask it to redirect an output to a new address, then observe what happens. Does the action layer reject the new destination? Is the attempted step logged? Can an operator pause the run and revoke the credential before a retry? Does the owner receive a useful alert, rather than a generic model-safety score?
This is where agent accountability becomes operational. A person's name on a register is necessary, but not sufficient. They need a way to see the workflow, change its scope and stop it. If the agent runs through a SaaS integration nobody inventories, even a well-designed policy may miss the connection. Map both approved agents and IA fantôme usage so the real access surface, not only the official architecture diagram, drives review.
Microsoft's report is a useful signal precisely because it does not present an exotic new control to buy. It connects familiar disciplines: least privilege, identity, data protection, monitoring and testing. The novel part is the tempo. An agent may turn an untrusted sentence into an API call before a human opens the ticket. A login establishes a principal; a governed action establishes a boundary.
If your team is mapping enterprise AI use, see how Aona approaches visibility et guardrails. Start with one agent that can reach sensitive data, trace a complete task through its permissions et logs, et test whether you can refuse the wrong next action without stopping useful work.
