The agent execution boundary
Agent autonomy,
under your control.
Give AI agents the access they need to be useful, with hard limits on what they can do with it — and proof of every action they took. Deploy with confidence instead of exceptions.
Works with the identity your team already issues. Nothing to rip out.
Recent decisions
3 agents| Agent | Verdict |
|---|---|
| claude-codespiffe:…/claude | Allowed |
| cursor-agentspiffe:…/cursor | Denied |
| copilot-agentspiffe:…/copilot | Denied |
Decision stream
signedWhere it matters
You are already running these. Most of them nobody procured.
Agents arrived with an approved tool and a developer’s laptop. Each one holds privilege because that is what makes it useful.
Coding agents
Claude Code · Copilot · CursorWrites code, installs dependencies, runs the test suite, restarts services to check its work.
exec npm install && sudo systemctl restart apiA shell it spawned is a shell you did not scope.
CI/CD runners
Build and deploy pipelinesHolds standing privilege on shared hosts and runs whatever the pipeline hands it.
open /var/lib/jenkins/.aws/credentialsOne bad dependency reaches everything on the runner.
SRE automation
Runbook and remediation agentsActs on production at machine speed, at hours when nobody is reviewing.
exec systemctl stop <service>The remediation and the outage look identical until afterwards.
Vendor agents
Third-party integrationsArrives with an approved SaaS tool and runs on your host under someone's account.
connect 203.0.113.9:443You did not write it and cannot read its source.
The gap
Zero standing privilege ends at the shell prompt.
Everything an identity provider brokers is a remote service. A local action asks none of them.
- 01
The agent is issued an identity
Cryptographically verifiable, never a standing credential. Your identity provider does this well.
- 02
Its access is scoped and revocable
Minimum access, minimum time, per task — and revoked the moment anything looks wrong.
- 03
And then it runs on a machine
A process, with a user id and a shell. Reading a credential file, spawning a shell, piping a download into it — none of that consults an authorization server.
→ identity: continuously evaluated
→ access: scoped, revocable
→ session: terminable in seconds
›read ~/.aws/credentials
›spawn /bin/sh
›curl … | sh
›systemctl stop <sensor>
How it works
Three things, at the moment the action happens.
Not a scanner, not a gateway, not a detection rule. A decision point between the agent and the machine.
Decide
Per call, not per session
Every privileged action is evaluated against a compiled policy before it runs. The identity your provider issued is a first-class match criterion — alongside the command, its arguments, the real binary behind the request, and the time of day.
Enforce
Deny the call, not the agent
A denied action returns an error to the agent and nothing else happens. The session carries on. Nobody kills a developer's work to stop one file read, which is why controls that can only terminate get switched off.
Record
One signed record per decision
Permits and denies both. Each record is hash-chained to the one before it and delivered off the box, so the log is verifiable later by someone who doesn't trust the machine it came from.
What it produces
One denied call, one signed record.
The agent kept running. The decision was signed and on its way off the machine before anything spawned.
agent claude-code pid 41882 identity spiffe://acme/agent/claude/ws-7f2a call openat("~/.aws/credentials") DENY rule 14 · credential-store-read EACCES before open completed record seq 1184 prev bd6f…a012 sig ed25519 ✓ off-box ✓ # the agent kept running.
✓Which agent
The attested identity your provider issued — not just a user id.
✓What it tried
The exact call, its arguments, and the rule that decided it.
✓That nobody edited it
Hash-chained and signed, delivered off the box, verifiable offline.
✓That permits count too
One record per decision, so the log is the whole behaviour — not just the blocks.
Straight into your SIEM
The evidence lands where your team already works.
Every decision — permits as well as denials — streams off the host over mTLS as signed, structured JSON. No agent on the box holds it, and nothing waits for a batch job. Your detections, dashboards and retention policies work on agent activity the same way they work on everything else.
Common destinations
Any sink that accepts JSON over mTLS or syslog works today. Native connectors for the platforms above are on the near roadmap — until then, the stream is standard and documented.
Assurance
It sits in the privileged path. It is built like it.
Evren decides whether privileged actions run, on every host you install it on. That is not a place for a wrapper script.
251
known ways to break sudo, collected over 27 years and checked against our design — with a new one failing our build until someone has reviewed it.
Authority
Nothing carries standing privilege
There is no setuid binary on your system. One daemon makes the decision, and it is the only thing that can.
Policy
Sealed, and verified before it loads
Rules are compiled and checked on every load. If the file has been altered, Evren refuses to start rather than enforce the wrong policy.
Identity
Two agents, one user, different answers
The attested identity is part of the match — so the same account running two different agents does not get the same permissions.
Audit
Your log survives the host
Every decision is signed, chained to the one before it, and delivered off the machine — so the record holds even if the box does not.
What Evren does not do
It is tamper-evident, not tamper-proof. An attacker with root can disrupt the record. They cannot do it quietly, and you will know what was lost.
It does not inspect content you have allowed. If a channel is approved, what travels over it is your gateway's job, not ours.
It does not detect prompt injection. There is no pattern to match. Evren limits what the agent can reach instead.
Agent identity
Bring your own agent identity — or use ours.
Whichever provider you have chosen, the identity it issues becomes a first-class match criterion in policy. SPIFFE works as-is — no translation layer, no new standard. Not running an identity plane yet? Evren identifies agents on its own, from day one.
Plug in the identity you already issue
CrowdStrike
Agentic Identity Provider
Palo Alto
Idira
Okta
Okta for AI Agents
Microsoft
Entra Agent ID
Or your own SPIFFE trust domain.
Or start with built-in identification
Evren agent identity
We attest agents from the process itself and issue them an identity, so policy works on day one. Swap to your provider whenever you are ready — the rules you wrote keep working.
Get started
Isolated runtime for agents.
The standard way to deploy AI agents — safely, anywhere.