Observer or governor? Why your AI control plane needs identity-first controls

Your API gateway can tell you an agent made a call. Your directory can tell you the agent authenticated. Neither can tell you what the agent did once it was inside, which team should pay for it, or stop it mid-action. That gap is the difference between watching agents and governing them.

Here’s what you’ll learn in this post:

• Why traffic monitors and directories observe agents but don’t govern them
• What “identity-first” means when every action, tool call, and model call resolves to a named agent
• Which enterprises can live with observation, and which ones need identity enforced at execution

Observers watch. Governors decide.

Two kinds of tools claim a role in agent security, and it’s worth being precise about what each actually does.

A traffic monitor like an API gateway sits beside your agents and inspects requests as they pass. It can log that a call happened, apply a rate limit, and match the request against a rule. It checks identity once, at the perimeter, and then waves the traffic through. After that, the agent is inside the building and the gateway is watching packets go by.

A directory like Okta or Entra answers a different question: is this a valid principal? It authenticates the agent and provisions its access. Once it hands over a token, it steps out of the path. It can confirm an action took place, but not what the action was, what the agent touched, or what was spent.

Both are useful observers. They tell you an agent acted, but they don’t govern what the agent is allowed to do at the moment it acts. Kong governs packets, not processes. It checks identity once the agent is already in the building.

What identity-first means

Identity-first governance starts from a different place: the agent’s identity is attached to the workload itself, and every action the agent takes resolves to that named identity.

The reason it can work this way is that the agent’s process runs inside a pod the control plane creates, on your Kubernetes cluster. The governor isn’t watching from adjacent infrastructure or inspecting traffic as it passes by. It runs the workload, so it’s in the path of every model call and every tool call by construction, not by interception.

That changes what identity can do. Instead of a check at the front door, identity travels with the agent through every step:

• Every action resolves to a named agent, at both the model gateway and the tool gateway. There are only two doors an agent can exit through, and identity is enforced at both.
• Tokens are short-lived and carry both a user ID and a role. There are no long-lived credentials sitting around to be replayed or shared.
• The agent’s lifecycle runs through your existing identity provider: OIDC for authentication, SCIM for provisioning, and Okta or Entra for access. Your directory still does what it’s good at; the governor does the part the directory can’t.

Why observation isn’t enough for high-stakes agents

The trouble with governing agents by watching traffic is that agents don’t behave like the clients that API gateways were built for.

Most enterprises today run their agents on shared service accounts, the kind of blanket credential they would never tolerate for a human employee. When ten agents share one service account, every action traces back to the account, not the agent. You can see that something happened, but you can’t see which agent did it, on whose behalf, or why. You can’t assign a guest badge to something that moves at machine speed and never sleeps.

Observation also can’t answer the question finance keeps asking. When an API gateway meters usage, it meters the account. When identity is attached to the workload, spend meters to a named identity, so your AI bill decomposes to an agent, a team, a workflow, and a dollar amount. You can see which agent is expensive and which team owns it.

And observation can’t stop what it only records. A monitor that checks identity at the perimeter and logs the rest is a camera, not a lock. For a low-risk agent that’s fine. For an agent touching regulated data or spending real money, you want identity to gate the action rather than appear beside it in the audit log. Assigning identity to a workload you don’t run is like naming a hurricane: you can label it, but you can’t govern it.

When observation is enough

Not every deployment needs identity enforced at execution. You’re likely fine with a traffic monitor and your existing directory if:

• Your agents are low-privilege and mostly read-only, so the blast radius of a shared account is small
• You need to know that actions happened for basic auditing, but you don’t need to attribute each one to a specific agent
• You’re not metering AI spend down to teams or workflows, so account-level usage data is sufficient
• Your agent count is low enough that shared service accounts are still manageable and easy to reason about

If that’s your situation, layering an API gateway and your IdP over your agents gives you reasonable visibility at low cost. Observation covers you until the stakes or the scale rise.

When you need identity-first governance

The value of identity-first climbs sharply once agents touch things that matter. You should insist on it if:

1. Your agents act on regulated or sensitive systems. When an agent can move money, read customer records, or change production, you need every action attributed to a named identity, not a shared account you’d never give a person.
2. You need per-agent accountability and cost. If you have to answer “which agent did this, for whom, and what did it cost?”, identity has to be attached to the workload, because a gateway meters the account and a directory logs the login.
3. You’re running agents at scale. Shared service accounts are workable for a handful of agents and unmanageable for hundreds. Identity-first keeps every agent distinct as the fleet grows.
4. You need to gate actions at execution. If your requirement is to stop a disallowed action before it completes rather than find it in the logs afterward, identity has to sit in the execution path.

If two or more of those describe you, an observer leaves you accountable for actions you can’t attribute and can’t stop. Identity-first closes that gap.

How Stacklok is identity-first

Stacklok governs agents by running them, so identity is enforced at execution rather than observed from the side.

• Stacklok runs the workload. The agent’s actual process runs inside a pod Stacklok creates on your Kubernetes cluster. Stacklok isn’t watching the agent from adjacent infrastructure or inspecting traffic as it passes by, so it enforces identity at every step rather than checking it once at the door.
• Identity is consistent at both doors. Every model call exits through the AI gateway and every tool call exits through the MCP gateway, and identity is handled the same way at each.
• There are zero long-lived tokens. Tokens are short-lived and carry both user ID and role, so there’s nothing durable to share or replay.
• Your existing IdP still runs the show. Stacklok uses OIDC for authentication, SCIM for provisioning, and Okta or Entra for access, managing the agent lifecycle through the directory you already operate.
• Spend resolves to a name. Because every action ties to a named identity, your AI bill decomposes to an agent, a team, a workflow, and a dollar amount.

The distinction with a traffic player is precise: Kong governs packets, not processes, and checks identity once the agent is already inside. Stacklok is the substrate the agent executes on, so it enforces identity at every step.

Get started

Want to see identity-first governance running on your own cluster, where every agent action resolves to a name? Book a demo or join the conversation and engage directly with our team on Discord.