Why your AI agents need an expiration date — and 4 other controls nobody ships
TL;DR: Your AI agents have permanent permissions, phone home to undeclared endpoints, and can't be shut down in under a second. Here are five controls that fix each of those — and why no incumbent IGA vendor ships any of them.
The AI-agent governance market has a pattern: take your existing policy engine, add an "AI" badge, and call it shipped. The result looks like governance on a slide deck and fails like paper in a fire.
After 26 years building identity governance at IBM and Oracle — and 18 months building SidantiX — I've identified five controls that separate real AI-agent safety from configuration theater. None of them are optional. All of them are absent from every major IGA product I've evaluated. Here's why each one matters, what it does, and what happens when you don't have it.
1. Per-agent egress allowlist
The problem: Your AI agent has HTTP client access. It can call any endpoint on the internet. You're trusting the model's alignment to not call endpoints it shouldn't — and every prompt-injection attack in the wild proves that trust is misplaced.
The control: Each agent declares, at bind time, exactly which external hosts and methods it may call. The outbound gateway enforces the allowlist at the network layer — not the application layer, not the model layer. A prompt-injected agent that tries to call an undeclared endpoint gets a signed denial receipt. The HTTP request never leaves your perimeter.
What happens without it: An injected agent exfiltrates your IAM credentials to an attacker-controlled endpoint. Your SIEM catches it 47 minutes later. By then the attacker has your entire AD forest.
Why nobody else ships it: Incumbent IGA vendors don't operate at the agent-runtime layer. They govern access to the agent, not access by the agent. SidantiX governs both because it was built for a world where AI agents are first-class identities.
2. Continuous constitution attestation
The problem: Your safety rules are loaded at boot and never checked again. If the in-memory rule set drifts — through a bug, a hot-patch, or an attacker modifying the running process — every subsequent decision runs against corrupted policy. And nothing tells you.
The control: The SHA-256 hash of the in-memory Machine Constitution is recomputed and verified against the boot-attested value on every single policy evaluation. Not once an hour. Not on a cron. On every action. If the hash doesn't match, the JVM halts immediately — no graceful degradation, no "log and continue." Dead process, no decisions made on corrupted rules.
What happens without it: An attacker who gains write access to the policy engine's heap can silently disable safety rules. Every decision after that point is governed by whatever the attacker left in place. Your audit trail shows "policy evaluated: ALLOW" — and the policy it evaluated against was the attacker's.
Why nobody else ships it: Runtime integrity checking on every request is expensive. It's also non-negotiable if you're serious about AI-agent safety. We eat the cost because the alternative — silent rule drift — is worse than any performance overhead.
3. Time-bounded delegations
The problem: You granted an AI agent the finance.read permission six months ago for a one-time reconciliation task. The task finished in an hour. The permission is still active. Nobody remembered to revoke it. This is the most common AI-agent vulnerability in every enterprise I've assessed — and it's the one that never shows up in a scan, because the permission is technically valid.
The control: Every permission grant, tool grant, and MCP delegation to an AI agent carries a mandatory expires_at timestamp. Default is 24 hours. Maximum is 90 days. There is no "permanent" option. When the grant expires, the policy engine refuses it — and the agent gets a signed denial receipt explaining why. Renewal requires a human operator to explicitly re-authorize, with a signed approval record.
What happens without it: Your AI agents accumulate permissions over time like sediment. Six months in, your "read-only reconciliation agent" has write access to three financial systems, admin on two cloud accounts, and tool grants to four APIs it no longer uses. When it gets compromised — and at enterprise scale, when is the right word — the blast radius is everything it was ever granted, not just what it needed today.
Why nobody else ships it: Forcing expiration on every grant is operationally disruptive. Teams complain about renewal fatigue. The alternative is a breach where the forensics report says "the agent had permissions it no longer needed, granted 187 days ago, never reviewed." Pick your disruption.
4. Adversarial red-team CI
The problem: You test your AI-agent guardrails manually, once, before launch. Nobody tests them again. Meanwhile, the prompt-injection research community publishes new attack patterns weekly. Your guardrails are six months stale, and you don't know it until a researcher tweets about bypassing them.
The control: A JUnit 5 parameterized test suite containing 200+ adversarial prompt patterns — seeded from the OWASP LLM Top 10 and updated continuously — runs on every CI build. The suite includes instruction override, role hijack, prompt exfiltration, self-elevation, tool escape, chain-of-thought manipulation, and multi-turn persistence attacks. 100% pass rate is required to merge. A single regression blocks the release pipeline.
What happens without it: You ship a guardrail update that accidentally weakens the self-elevation detector. Nobody notices. Three weeks later, a prompt-injection attack succeeds in production. The post-incident review discovers the regression was introduced in a routine refactor and would have been caught by any automated test.
Why nobody else ships it: Most vendors treat AI safety testing as a one-time penetration test, not a continuous regression suite. They don't have the attack corpus, and they don't have the CI integration. We run the red team on every build because the attack surface changes faster than quarterly pen tests can track.
5. Kill-switch SLO — elevated to constitutional law
The problem: Your AI agent is misbehaving. You hit the kill switch. It takes 8 seconds to propagate. In those 8 seconds, the agent makes 47 more decisions. Some of them involve write access to production systems. Your kill switch is a suggestion, not a guarantee.
The control: A synthetic kill-switch drill runs every 60 seconds on every control-plane node. The drill measures propagation latency end-to-end. If a node misses the SLO (under 1 second) three consecutive times, it automatically drains itself — stops accepting new requests via health-probe 503, finishes in-flight work, and goes dark. No human intervention required. The SLO isn't a monitoring metric — it's a Machine Constitution rule, enforced with the same cryptographic rigor as every other safety invariant.
What happens without it: You discover during an incident that your kill switch takes 12 seconds to propagate because one control-plane node has a stale connection pool. By the time all nodes acknowledge the kill, the agent has already executed the actions you were trying to prevent. Your incident report says "kill switch activated at 14:32:07, agent continued operating until 14:32:19."
Why nobody else ships it: Treating kill-switch latency as a constitutional requirement — not a best-effort SLI — requires the same infrastructure that makes the Machine Constitution work: runtime-immutable rules, continuous attestation, and automatic enforcement without human intervention. You can't bolt this onto an existing policy engine. It has to be designed in from day one.
The pattern
All five controls share a design principle: enforcement that doesn't depend on the thing being enforced.
- Egress allowlists enforce at the network gateway, not the agent runtime.
- Constitution attestation verifies from outside the policy engine's own memory.
- Time-bounded delegations expire at the grant layer, not the agent layer.
- Red-team CI runs in the build pipeline, not inside the product.
- Kill-switch SLO is measured by the health probe, not the agent process.
If you let the agent enforce its own safety, you've delegated security to the thing you're trying to secure. That's not governance — it's hope.
What to do next
If you're evaluating AI-agent governance vendors, add these five controls to your RFP. If a vendor can't demonstrate them, ask why. If the answer is "it's on our roadmap," ask when — and whether their architecture can support runtime-immutable rules at all, or whether they'd need to rebuild from scratch.
We built SidantiX for a world where AI agents are first-class identities with first-class risk. These five controls are table stakes for that world. They should be table stakes for yours.
See these controls in action — try the Self Experience, start a 30-day free trial, or talk to the founder.