AI Agent Identity Security: Where an Agent’s Baseline Lives

Identity governance cannot tell you which AI agent did something. It records which identity is allowed what. In a cluster, one service account often serves several workloads, and every pod is replaced at the next rollout. As a result, the permission record and the behavior record point at different objects.

Detection and investigation need a unit of attribution. The Deployment is the right one. It stays stable across restarts and replicas and changes only when someone ships a rollout.

This article sets out why governance asks one question and investigation asks another. It covers the three candidates for the unit of attribution, why the pod becomes the default and what it costs, and what a Deployment-level baseline survives. It then explains how batch agents on Jobs and CronJobs fit and closes with the two hygiene rules that make attribution possible.

What AI agent identity security covers

AI agent identity security ties an agent’s permissions and actions to a named, accountable identity. It contains two jobs. It governs what each identity may reach, and it attributes each observed action to the agent that performed it.

Governance decides which identity may call which API, read which secret or invoke which tool, and it reviews those grants over time. Attribution works backward from an action that already happened and names the agent behind it.

Both jobs use the word identity, but they need different objects to hold it. Governance anchors on whatever the authorization system checks. Attribution anchors on whatever stays the same for as long as an agent keeps behaving like itself.

Governance asks one question, investigation asks another

Governance asks which identity is allowed what. The answer lives in RBAC bindings and cloud IAM policies attached to a service account. An entitlement review of those grants finds unused permissions and roles broader than the work.

Those grants decide whether each call passes the authorization check. A call that passes is an allowed action, and governance stops at the allowed action.

The allowed action is also where an alert starts. A data read the agent has never made, or a connection to a new destination, passes every check and can still be the first step of an incident.

The first question that alert raises is which agent did this. The authorization record names the identity that held the permission. When several workloads share that identity, the record points at all of them.

Answering the question starts with tying runtime telemetry to a workload. Without entity identity resolved to that level, no per-agent profile can be assembled. Once telemetry reaches a workload, the remaining choice is which workload object carries it.

Three candidates for the unit of attribution

A unit of attribution has to pass two tests. It has to be specific to one agent, and it has to stay stable while that agent’s behavior stays the same. Three Kubernetes objects sit close enough to an agent to compete for the job: the ServiceAccount, the Pod and the Deployment.

The ServiceAccount

The ServiceAccount passes the stability test and fails the specificity test.

A service account outlives every pod that mounts it, and it is shared by design. Every replica of a Deployment runs under the same account. Teams often bind several Deployments to one account so they can share an IAM role. Any pod that names no service account runs as the namespace’s default service account.

An event attributed to a service account therefore names a group of workloads. Identity-layer detection needs per-agent identity tags for this reason, so that each event resolves to one agent even when the account behind it is shared.

The Pod

The Pod passes the specificity test and fails the stability test.

A pod is one running instance, so every event it produces belongs to it alone. A pod is also disposable. Kubernetes replaces it at every rollout, and whenever it is evicted, preempted or lost with its node. A Deployment’s replacement pod gets a new name and a new UID, and the history recorded under the old pod ends with that pod.

The Deployment

The Deployment passes both tests.

A Deployment names one application and keeps that name while its pods come and go. Pod replacements, rescheduling and scaling all leave it in place. The Deployment itself changes when its pod template changes. That change triggers a rollout, and a rollout is a recorded event with a revision number. Scaling does not trigger one.

The Deployment’s stability ends when the object itself is replaced. A rename, a delete-and-recreate sync or a reinstall creates a new Deployment, and a baseline keyed to it starts over. Release tooling should update Deployments in place.

A StatefulSet fills the same role for agents that need stable storage.

Why the pod becomes the default, and what it costs

The pod becomes the default because telemetry is collected at the pod. A runtime sensor sees processes, file access and network connections inside a container, and the nearest Kubernetes name for that container is its pod.

A baseline built from that telemetry keeps the pod as its key unless the pipeline maps the pod up to its owner. The mapping exists in the cluster. Each Deployment pod carries an owner reference to a ReplicaSet, and that ReplicaSet carries one to its Deployment. Where a collection pipeline skips that resolution, the baseline stays keyed to the pod.

A pod-keyed baseline lasts as long as the pod. The next rollout replaces every pod, and each replacement starts with an empty history. An agent that ships weekly never accumulates more than a week of normal behavior. An agent on nodes that autoscaling consolidates loses its pods, and their history, between releases.

An empty history leaves detection two options. Alerting on everything new floods the queue after every deploy. Suppressing alerts while the new baseline learns opens a window that reappears at every release.

An alert raised in either state has no history behind it. The analyst sees a pod name that may already be gone and cannot tell whether the behavior is new for the agent or only new for the pod.

What a Deployment-level baseline survives

A Deployment-level baseline survives everything that replaces pods without changing the application. Container restarts, node drains, evictions and rescheduling leave it intact. So do scaling events, whether a person changed the replica count or an autoscaler did.

The baseline also pools its replicas. Five replicas of one agent contribute five streams of observed behavior to one profile, so the profile sees more of the agent’s normal variety in less time, as long as the replicas share the same work.

The baseline gets its boundary from the rollout. Behavior that changes when a new revision ships is expected to change, and the team that shipped it can confirm the change. Behavior that changes with no rollout behind it has no release to explain it, which puts it first in line for investigation.

The boundary holds only if every behavior-changing release goes through the pod template. A new model version, a revised system prompt or a new tool definition loaded from a ConfigMap changes the agent without changing the template, so the cluster records no rollout. Put a version or content hash for each of them in the template.

ARMO’s runtime behavioral security builds its Application Profile DNA (APD™) baseline at the Deployment level for these reasons. Each agent gets one behavioral profile that outlives its pods, and an attack story built on that profile names one workload.

Batch agents: Jobs and CronJobs

Batch agents follow the same rule with a different owning object. A Job creates pods that are meant to finish, so a pod-keyed baseline for a batch agent is empty by design.

The CronJob is the stable name for a scheduled agent. Each scheduled run creates a new Job with a new name, and each Job creates its own pods. The CronJob persists across every run, and its job template defines what every run does. The baseline belongs to the CronJob.

A job template change plays the role a rollout plays for a Deployment. Runs on either side of the change are expected to differ. Runs with no template change between them are expected to match.

One-off Jobs launched by a pipeline or controller need a stable name supplied by the launcher, since each Job is new. The launcher stamps the same agent label on every Job it creates, and that label becomes the unit of attribution.

Two hygiene rules that make attribution possible

A Deployment-level baseline works only when workload objects map cleanly onto agents, and two hygiene rules create that mapping: one agent per workload object, and one service account per workload object.

One agent per workload object keeps each behavioral profile specific. Two agents in one Deployment produce one blended profile. Neither agent’s normal behavior is visible in it, and a deviation by either can hide inside the other’s range.

One service account per workload object makes the authorization record and the behavior record agree. When a Deployment has its own account, the identity in an audit log and the workload in a behavioral alert name the same agent. That match is also what lets runtime-derived least privilege bind a policy derived from one agent’s behavior to an identity no other workload uses.

Several agents in one pod break both rules at once. They share a workload object and a service account, so attribution stops at the pod’s owner and cannot separate one agent from the next.

An alert you cannot attribute is an alert you cannot act on

Every response action operates on a workload object. Rolling back a bad release, scaling an agent to zero and paging the team that owns it all start from a Deployment or CronJob name.

An alert keyed to a pod names an object that may no longer exist. An alert keyed to a shared service account names several workloads and leaves the responder to pick one. An alert keyed to the Deployment names the one object the responder can roll back, contain or hand to its owner.

Open the last agent alert your stack produced and read the object it names. A pod name means the history behind that alert is as old as your last deploy. A service account name means the alert covers every workload bound to it. If either is what you find, the unit of attribution is already decided, and it was decided by whatever collects your telemetry rather than by you. ARMO baselines each agent at the Deployment level, so an alert arrives with one workload name and the history to judge it against. Book a demo to see what your own agents’ baselines look like at that level.

FAQ

Should every AI agent get its own service account?

Every agent that runs as its own workload object should have its own service account. That keeps authorization records and behavioral records pointed at the same agent, and it lets you scope the account to that agent’s observed needs. Replicas of one Deployment share the account, which is correct because they run the same agent. The pattern to remove is several Deployments sharing one account to save IAM setup.

How do I attribute actions when several agents share a pod today?

Record which agents live in which pods, and treat each such pod’s owner as one unit with a blended profile. Then split the agents into separate Deployments, starting with the agent that holds the most privileged tools or data access. Where agents share a single process and cannot be split yet, application-level records have to carry each agent’s name, because nothing below the application can tell them apart. Schedule the split for that workload’s next release.

What happens to the baseline when we roll out a new model version?

The rollout marks where expected change begins, so behavior after the new revision is reviewed against the release that introduced it. That works only if the model version lives in the pod template as an image tag, an environment variable or an annotation. A version set in a ConfigMap, or behind a provider-side model alias, reaches the agent with no rollout recorded. Move those values into the template or stamp a hash of them there; Kustomize’s ConfigMap generator does this automatically by adding a content hash to the ConfigMap name.

Does this work for agents that run as Jobs or CronJobs?

It works for scheduled agents, because a CronJob keeps one name across every run and its job template changes only when someone edits it. Bind the baseline to the CronJob and treat a job template change as that agent’s release. One-off Jobs launched by a pipeline need a consistent agent label applied at creation, since each Job has a new name. Without that label, every run starts with no history.

How does this relate to the non-human identity tooling we already run?

Non-human identity tooling governs which identities exist, what they are granted and whether those grants are still used. It answers the governance question and leaves attribution to whatever produces your behavioral alerts. The two meet at the service account, so with one service account per workload object, a finding from your identity tooling and an alert from runtime detection name the same agent.