Your identity stack stops at the network edge
Short-lived tokens and continuous evaluation are the right answer for remote services. None of it reaches the host — and that is where agents actually act.
The industry has converged on the right first answer to agent security: give every agent a verifiable identity. CrowdStrike began issuing SPIFFE identities to agents at Fal.Con. Okta is moving the same direction. The standards work is real and the engineering behind it is good.
It is also incomplete in a specific, structural way, and the gap is not one more feature on the identity roadmap.
What the identity layer actually brokers
Think about what an identity provider is in the path of. It issues a token. That token is presented to a service — Salesforce, GitHub, the cloud console, an internal API behind a gateway. The service validates it, checks scope, and serves or refuses the request.
Every one of those is a remote service. The authorization decision happens because a network request arrives somewhere that knows how to ask the question.
Now consider what an agent does on the machine it is running on:
cat ~/.aws/credentials
systemctl stop <sensor>
curl https://… | sh
exec /bin/shNo authorization server is consulted for any of these. There is no token exchange, no scope check, no policy decision point in the path. The kernel asks one question — does this uid have permission — and the answer was decided when the process started.
Why revocation does not help here
The strongest claim the identity layer makes is speed of revocation: anomaly detected, session terminated, access removed, seconds not hours. That is genuinely impressive and it is the right design for what it covers.
But revocation operates on the thing it issued. Revoking a token stops the agent reaching Salesforce. It does not stop the agent reading a credential file that was sitting on disk, spawning a shell, or stopping the process that would have reported any of it — because none of those ever asked the identity provider for anything.
Zero standing privilege is a property of your remote access. It is not a property of the host.
“Then run the agent as a low-privileged user”
This is the obvious objection and it is worth taking seriously, because for a long time it was the right answer.
It breaks down for two reasons. The first is that agents are deployed precisely because they are useful, and useful means installing packages, restarting services, reading configuration, writing to shared paths. The privilege is not an accident — somebody granted it on purpose, because the agent could not do its job without it.
The second is that a uid is the wrong unit. Five agents sharing one service account are one identity to the kernel and one line in the audit log. When something goes wrong at 3am you cannot answer which agent did it, and when you write policy you cannot express “the research agent may read this; the deployment agent may not” — because to the operating system they are the same actor.
What sits in the gap
The missing control is narrow and it is specific: a decision point on the host, in the path of privileged action, that knows which agent is asking.
Concretely, that means four things:
- Decide per call, not per session. A permit is not a door held open for the rest of the process lifetime.
- Match on attested agent identity, not on uid — and over a process-ancestry floor, so a child cannot hold more reach than its parent.
- Confine what the permitted process can reach — file paths and syscalls — rather than trusting it to behave once it has started.
- Write the decision somewhere the host cannot edit. A log line on a box an attacker just took is not evidence.
This is additive, not competitive
None of this replaces the identity layer, and building a competing one would be a mistake. The identity provider answers who the agent is, and does it well. We want that answer — it is the input.
If you already issue SPIFFE identities, that identity becomes the policy predicate at the point of execution, with no translation layer in between. Your IdP keeps issuing. Your SIEM keeps receiving. What gets added is the decision that currently has no owner: what a given agent may actually do on a given machine.
Identity says who. Something else has to say what happens next.