Agent Identity and Access: Why Your Enterprise Permissions Were Built for Humans (and How to Fix Them)

Your identity provider expects a human. It expects a password and a session cookie tied to a browser. Agents don't have browsers. They run in background jobs on cloud infrastructure. When an agent needs to read a ticket from your issue tracker or draft an update in your CRM, it hits a wall. The system asks for an interactive login.

Most teams solve this by creating a shared service account. They give the agent a username and password, or a long-lived API key. The agent uses these credentials to log in as a fake human. This breaks down immediately. Service accounts don't have managers. They don't attend access reviews. Permissions accumulate over time. The account gets read access to the marketing database, write access to the billing system, and admin rights to the file storage. If an attacker compromises the agent, they get the keys to everything.

Identities must map to the actions agents perform. An agent that drafts summaries of internal documents needs read access to those documents. It doesn't need the ability to delete files. Human identity systems group permissions into broad roles to reduce cognitive load. A human administrator can manage fifty permissions. A human user just wants to log in and do their job. Agents don't care about cognitive load. They can handle specific, restrictive rules.

The Limits of Role-Based Access

Standard role-based access control assigns a static set of permissions to an entity. You assign an agent the analyst role. The analyst role lets it run queries and export data. The problem is context. An agent running a query to answer a user question shouldn't have the same permissions as an agent running a scheduled data cleanup job. Both are agents, but their scope differs entirely.

If the query agent gets compromised, the attacker can export your entire customer database. If you want to prevent this, you might try modifying the role. You remove export privileges. Now the cleanup job fails because it needed export privileges to write the archive file. Static roles force you into an uncomfortable tradeoff. You give agents broad access so they can do their jobs, or you restrict them so tightly that they fail silently in production. Neither option is secure.

What would change my mind here is evidence that static roles can be scoped tightly enough for autonomous workloads without breaking. If you can show me a system where five hundred agents operate securely on a five-permission role, I will reconsider. In practice, agents need access to dozens of systems. A five-permission role is a fantasy.

Building an Agent Identity Broker

We need an identity layer built for autonomous workloads. Agents shouldn't hold long-lived credentials. They should request access right before they decide to do something. This requires an identity broker. The broker sits between the agent and the target system.

Here is how it works. The agent decides it needs to read a specific ticket. It sends a request to the broker. The request contains the agent workload identity, the target system, the specific action, and the context of the request. The broker evaluates this request against a policy. If the policy allows it, the broker issues a short-lived token. The token is valid for five minutes. The token only grants read access to that specific ticket.

This approach decouples the agent identity from the target system authentication mechanism. The target system doesn't need to know what an agent is. It just validates a token. The broker handles the complexity. The design work is mapping each agent capability to the target system API, so agents never need to know how a given system authenticates. They ask the broker for a token to draft a record, and the broker deals with the protocol on the other side.

Just-In-Time Attribute Tokens

The broker needs a policy engine. Attribute-based access control fits this requirement. You define policies based on attributes of the request.

Consider an agent that drafts financial reports. The agent has the attribute department: finance. The target system is your document repository. The action is write. The resource is the Q3_Report folder. A policy might state that an agent with department: finance can write to Q3_Report during business hours. The broker checks the current time. If it is 2 PM, the broker issues the token. If the agent tries to run the report generation job at midnight, the broker denies the request.

You can layer attributes. Add an attribute for data_sensitivity. An agent drafting a public blog post gets a token with data_sensitivity: public. If that agent tries to read a document marked data_sensitivity: confidential, the broker denies the request. This context-aware scoping is impossible with static service accounts. The service account either has access or it doesn't. The broker evaluates the current state of the world.

Handling Failures and Audits

Short-lived tokens solve the access problem, but they create an observability challenge. When an agent acts, you need to know exactly what it did. Traditional audit logs point to a user. They say jane.doe@example.com updated the file. If five agents use the same service account, the audit log says service_account_1 updated the file. You have no idea which agent ran the query.

The broker fixes this by acting as a choke point. Every request flows through the broker. The broker logs the agent workload identity, the requested action, the issued token, and the timestamp. When an incident occurs, you query the broker logs. You find the exact agent that exported the billing data.

This assumes the broker is online. If the broker goes down, agents can't request tokens. They fail to do their jobs. You must design the broker for high availability. Running it across multiple availability zones is a baseline requirement. You also need a fallback mechanism. If the broker is unavailable, agents should fail closed. They shouldn't fall back to a cached credential. If an agent caches a token and the broker dies, the agent can still act until the token expires. After expiration, it must stop. That hard stop is worth enforcing in code rather than trusting to convention.