Identity: who gets in, and who is really there?

Think of a school building with many doors. At each door, someone checks who you are and where you are allowed to go.

Security people use the idea of a control plane for this. A control plane is any boundary where a system has to prove who it is, what it can touch, and what happens once it acts.

“A control plane is any boundary inside an organization where a system has to prove who it is, what it can touch, and what happens once it acts.”

The 10 Control Planes framework lists ten such boundaries. Each one has a security tool built for it. The tool for identity is called IAM, which stands for identity and access management.

“Security tools have been developed for each of these boundaries over roughly the last two decades: IAM for identity, a CASB for SaaS traffic, an API gateway for machine-to-machine calls, EDR for a laptop.”

The Identity plane is the one that governs users, service accounts, sign-in permissions, and role-based access. Role-based access means what you may do depends on your role.

“Governs:Users, service accounts, OAuth grants, and role-based access scopes.”

Older security tools expect two kinds of users. A person logs in once and then acts like a person. A script does the same few steps in the same order every night.

“A person logs in once and behaves like a person for the rest of the session. A script calls the same three endpoints in the same order every night.”

An AI agent is different. It reads, decides which system to touch next, and repeats that loop for as long as the task takes.

“An autonomous agent, however, authenticates, reasons about what it just read, decides on its own which system to touch next, and repeats that loop for as long as the task takes.”

An agent usually signs in once, with a service account or token that was set up in advance. From then on, every action it takes inherits the permissions of that identity.

“It authenticates once, using a service account or token provisioned at setup, and every action from that point inherits that identity's permissions.”

One example from the articles is an AI plugin that signs in once as an admin. After that, every seller on the sales team inherits that access. Old identity tools see one service account connection. They do not see all the activity that follows.

“the plugin authenticates once at the admin level, then every seller inherits access.”

“Traditional IAM tools see one service account connection, not the distributed query load that follows.”

Identity tools such as IAM check that a login is valid on every call. What they cannot do is ask whether the behaviour fits the reason the access was given.

“Identity and access management (IAM) confirms validity on every call. It has no mechanism for asking whether the behavior matches the purpose the access was granted for.”

This matters more as machine accounts pile up. The article says non-human identities already outnumber human users in most companies. Service accounts are often copied from human roles and never trimmed down.

“non-human identities already outnumbering human users in most enterprises”

“service accounts routinely cloned from human roles and never scoped down”

An agent also crosses several control planes in one task. Each plane has a tool built for human speed. The article says the gaps between planes are structural, and agents fall through them.

“The native controls on each individual plane were designed for human operators moving at human speed.”

“The gaps between planes are structural, and agents fall through them.”

The article gives one clear fix. Give the service account only the specific objects the agent needs for its task, not the full role a person in that job would have. Then tie how long the token lasts to how long the job should take.

“Scope the service account to the specific objects the agent needs for its task, not the role a human in that function would carry, and bind the token's lifespan to the expected execution window. A twenty-minute job shouldn't hold an eight-hour credential.”

A weak identity is often the way in, not the place where the harm happens. A stolen login lets an attacker reach other systems, and the damage shows up there.

“the failure here is what made the outer-ring damage possible, not the outer-ring damage itself.”

A real finding makes the point. A security research team called Unit 42 found that overly generous default service-account permissions, not a brand-new AI trick, did the damage on Google's Vertex AI.

“Unit 42's "Double Agent" finding on Google's Vertex AI is named and specific: excessive default service-account permissions, not a novel AI vulnerability, doing the damage.”