AI agent identity security: permissions before autonomy

An AI agent that can read a document is a useful feature. An AI agent that can read every document, send email, change customer records and deploy infrastructure is a small internal government with no opposition party.

The security question is no longer simply whether the model gives a sensible answer. It is whether the software can prove which agent acted, whose authority it used, what it was allowed to touch, which checks ran and how its access can be stopped.

That question is especially current this week. The SANS Cloud Security Exchange on 17 and 18 August brings AWS, Google Cloud, Microsoft and Anthropic into a programme focused on autonomous agents in cloud security. SANS makes the central problem plain: identity and response systems designed around human activity are being asked to govern software that can authenticate and complete multi-step work at machine speed.

For founders, the answer is not to wait for a grand universal standard. It is to treat agent identity, permissions and evidence as product architecture before autonomy reaches production.

An agent is not a clever employee account

Many prototypes begin with the credentials already available to the developer. The agent inherits a broad API key, a service account or the founder's own access because this is convenient and the demo is on Friday.

The arrangement works beautifully until nobody can distinguish the agent's actions from the developer's, a test agent can see production data, or an instruction hidden in a document causes a tool call nobody intended. Convenience has quietly become ambient authority.

A production agent needs a distinct identity. That identity should identify the agent itself, its environment, owner, purpose and permitted resources. It should not share credentials with unrelated agents or rely on a human account that will eventually change role, leave the company or acquire even more permissions.

Google recently described Agent Identity as a native IAM type intended to bind access to the runtime, support least privilege and manage the identity lifecycle. Microsoft's Entra Agent ID guidance similarly recommends separate credentials across environments, managed identities or certificates in production, agent-specific access policies and ongoing access reviews.

Different platforms use different machinery. The principle is reassuringly unfashionable: know what is logging in.

Authentication answers only the first question

A valid identity proves who or what presented a credential. It does not prove that the requested action is appropriate.

This matters because an agent does not merely call one endpoint. It reads an instruction, collects context, chooses tools, supplies arguments, observes results and decides what to do next. A harmless first step can create a damaging sequence when every downstream system sees a valid token and politely opens the door.

OWASP describes excessive agency through three related problems: too much functionality, too much permission and too much autonomy. Its examples are ordinary enough to be uncomfortable. A reading tool also has delete functions. A database connection intended for recommendations can write to customer tables. A generic privileged identity acts for every user.

The model is not the authorization system. Every tool and downstream service should enforce its own boundary, even when the agent is extremely confident and has composed a paragraph explaining why the boundary is inconvenient.

Five controls to build before launch

1. Give every agent a named owner and purpose

Record who is accountable for the agent, what business job it performs, which environment it belongs to and when its access should expire or be reviewed. A catalogue need not be ceremonial. It must be accurate enough to answer which agents exist and who can disable them.

Separate development, testing and production identities. Do not allow an experimental agent to accumulate production access as it progresses through environments. Promotion should create or approve a production identity with production-specific controls.

2. Scope permissions to the smallest useful action

Permissions should follow the product job, not the complete capabilities of a vendor connector. A support agent may need to read a ticket and draft a reply. It does not therefore need to send the reply, export the customer database or administer the helpdesk.

Microsoft's access-pattern guidance recommends preserving user-level authorization when an agent acts for a signed-in user, and using the smallest app-only permissions for background automation. It also separates read, draft, send, delete and infrastructure changes because they carry very different consequences.

Build narrow tools where possible. A function that updates one approved CRM field is easier to govern than a general function that can issue arbitrary API requests. General-purpose shells and unrestricted URL fetchers are flexible in the same way a master key is flexible.

3. Put approval at the point of consequence

Approval should sit immediately before the external effect, with the proposed action and relevant context visible to the reviewer. Approving a vague objective at the beginning of a long autonomous run is not the same as approving the payment, deletion, publication or permission change it eventually produces.

Low-risk reads can often proceed automatically. Drafting can usually be separated from sending. Changes to infrastructure, permissions, money, public content or customer data deserve policy checks and, in many cases, explicit human approval.

4. Use short-lived credentials and a real stop button

Long-lived secrets spread through configuration, logs and hurried integrations. Prefer managed or federated identities where the platform supports them, narrow token audiences and lifetimes, and keep secrets out of prompts and model context.

Design revocation before launch. A team should be able to disable one agent, one tool or one environment without taking the whole product offline. Kill switches that require a new deployment and three people to remember an undocumented command are less a control than an escape-room theme.

5. Log the decision chain, not only the final API call

Traditional audit logs may show that a service account updated a record. An agent investigation also needs the initiating user or job, agent identity, policy version, tool selected, arguments approved, downstream identity, result and correlation ID.

Be careful with the other extreme. Logging every prompt and response can create a fresh store of customer data, credentials and sensitive context. Record enough structured evidence to reconstruct consequential actions, apply retention rules and redact secrets at collection.

Test identity failure as a product journey

Recent reporting on agents moving beyond test boundaries is a useful reminder that containment assumptions deserve practical testing. The lesson is not that every agent is plotting an escape. It is that capable software will use the resources and routes available to it, including ones the team forgot were available.

Test what happens when an instruction is malicious, a tool returns unexpected content, a token is stolen, a user loses access halfway through a task, an approval expires, an agent calls tools in the wrong order or a production identity appears in a test environment.

Verify denial as carefully as success. The product should fail closed, explain the blocked action to the right person, preserve useful evidence and avoid retrying a forbidden operation until somebody mistakes persistence for permission.

What launch-ready looks like

A launch-ready agent has a distinct identity, a named owner, narrow tools, minimum permissions, separate environments, approval gates for consequential actions, short-lived credentials, monitored activity and a tested revocation path.

It also has an honest product boundary. Some tasks should remain drafts. Some should require a person. Some should never be delegated to a general-purpose agent with access to unrelated systems, however impressive the demonstration looked.

AI agents make software feel less like a passive interface and more like a participant in operations. That can be valuable, but participation requires accountability. Autonomy without identity is not a product strategy. It is merely a difficult incident report that has not happened yet.

If your agent can already call production tools but nobody can quickly explain its credentials, scopes, approvals and stop path, show Venturist what you have built. A focused product audit can turn the prototype into a controlled release before access expands by accident.