Squares and Rectangles: Why AI Agents Can’t Be Treated Like Regular Workloads

When your organization deploys an AI agent, the instinct is to reach for the nearest familiar category. Agents are software: they make API calls, they run on infrastructure your team already manages, and they take action at the direction of users.

 If agents are just software talking to other software, you should treat them like a workload: issue a service account credential, scope it as tightly as the timeline allows, and move on. And agents are software, just like squares are rectangles. But just because a category fits doesn’t mean it is the best fit. 

As I’ve worked with developers and users to understand how AI agents behave in organizations, I’ve seen that that instinct is wrong. Not because it comes from a bad place, but because the category misses critical context, so the security model built on top of it has gaps – gaps that don’t announce themselves until something goes wrong.

AI agents are a new identity class. They share properties with workloads and properties with human users, but they’re identical to neither. And the security model that governs their access needs to be built for what they actually are, not mapped onto the closest existing approximation. Not workload identity that treats them like just another type of software and not as an extension of the user’s identity, but through a blended identity that encompasses the context and access requirements of both. 

Why the Traditional Workload Model Falls Short

There are a few ways that a traditional workload identity approach can fall short for AI agents.

The Scope Problem

Traditional workloads generally operate within a defined application architecture and an expected permission boundary. A microservice hits a specific endpoint in a specific sequence. A scheduled job reads from a defined set of resources. You can model the access pattern, write a tightly scoped credential, and trust that the service will stay inside the lines.

AI agents are also software, but they aren’t deterministic. An AI agent doesn’t have a fixed access pattern. Claude completing a research task might need to reach a document repository, an internal knowledge base, and an external data API – in an order determined at runtime, based on the content of the request it received. The path through the system isn’t known in advance. Instead, it’s inferred, mid-task, by the model itself. 

That makes it harder to scope a credential in advance to the access the agent will actually need, because the exact behavior may not be known until runtime. Some approaches over-permission, scoping behavior too broadly to get ahead of access requests. On the flip side, scoping tightly causes tasks to fail or inundates users and security teams with access requests. 

The Standing Access Problem

Issuing a static credential to an AI agent means that credential exists continuously, available to whatever can reach it, with whatever permissions were granted at provisioning time. For a deterministic service, that’s a manageable risk, because workload behavior can be predicted, so the blast radius is bounded. 

For an agent that exercises judgment about what to access, when, and in what sequence, standing access is a different proposition. The agent’s behavior can change with a model update, a prompt change, or a new tool integration, without anyone on the security team knowing it changed. A credential scoped for one behavioral profile is now being held by an entity that doesn’t match that profile anymore. The blast radius is as large as whatever the credential can reach.

The Attribution Problem

When the compliance team asks which systems a given agent accessed on a given date, the answer from standard tooling is incomplete. Server logs may capture a service account or application identity without preserving the full context of which agent acted or which user’s session triggered it.

 In an environment where multiple agents share infrastructure, that distinction matters enormously. You know something accessed a resource. You don’t know which agent, which user’s session triggered it, or what policy was supposed to authorize it.

Blended Identity is the Model Agents Need

So why does the workload model fail? Because agents aren’t predictable or deterministic. They can make extremely unpredictable decisions while acting faster than humans can respond. 

What AI agents actually require is a hybrid: a model that preserves the agent’s own identity while also incorporating the identity and context of the user on whose behalf it is acting.  At Aembit, we call this a blended identity approach to reflect the reality that agents don’t fit cleanly into either existing category.

In practice, blended identity means credentials are issued at runtime, scoped to the specific task the agent is performing, and expire when that task is done. There’s no static key sitting in a config file. There’s no credential that outlives its purpose. Every issuance is based on a policy – evaluated against what agent is requesting access, to what resource, under what conditions – and every decision is logged with enough context to answer compliance questions.

As a result, agents are governed by IAM that keeps pace with agent behavior at machine speed, while maintaining the policy control and audit accountability that security teams need to operate confidently in a regulated environment.

It’s Possible to Deploy Agents Securely, Without Delaying Rollout

Security teams are clear-eyed that something must be done to manage agent identity and access. The risk is applying a reasonable mental model to the wrong category of entity, creating gaps that aren’t visible until they’re suddenly very, very consequential.

AI agents are being deployed now, under time pressure, by business units that aren’t waiting for security frameworks to catch up. The teams inheriting the security question are doing what any thoughtful team would do: reaching for the closest available tool. In most cases, that means workload identity or service account provisioning.

The correct response isn’t to slow down deployment – that’s not realistic in most organizations, and slowing it down doesn’t solve the access problem, it just means the problem goes unaddressed. Instead, teams need to recognize that AI agents require a new approach, and implement it before the deployment happens rather than in response to what the deployment reveals.

Squares are rectangles and AI agents are workloads, but they require more than just workloads with a more interesting runtime. Blended identity is the right approach.