The moment that crystallised the AI agent safety problem for many engineers happened not in a dramatic failure but in a quiet one. A production agent — deployed to handle customer refund processing — got stuck in a loop. It processed the same refund request 847 times over six hours before anyone noticed. Each transaction was individually valid. The agent was doing exactly what it was told. It just would not stop.
The total cost was recoverable. But the incident exposed a fundamental gap in the organisation's safety architecture: they had no circuit breaker. No mechanism to detect runaway behaviour. No way to halt the agent without taking down the entire system it was part of.
This is the problem that auto-revocation solves. Not the dramatic failure — the AI agent gone rogue — but the quieter, more common failure mode: an agent that continues doing something harmful because nothing in the system is designed to stop it.
The Three Failure Modes That Require Revocation
Before designing a revocation system, it is worth being precise about what you are designing it for. There are three distinct failure modes that should trigger agent revocation.
Behavioural drift is the most common. An agent that was performing within acceptable parameters begins to behave differently. The change is not dramatic — it is gradual. Transaction volumes creep up. The distribution of data sources accessed shifts. API call rates increase slowly. No single event is clearly wrong, but the aggregate pattern has moved outside the historical baseline. Left unchecked, drift often precedes more significant failures. Auto-revocation at a defined risk threshold catches drift before it becomes a crisis.
Security compromise is less common but higher stakes. An agent's credentials have been stolen, or the agent has been successfully targeted by a prompt injection attack, and it is now executing instructions from an attacker rather than its legitimate operator. The behavioural signal here is often more abrupt: a sudden spike in data access events, calls to unusual external endpoints, or authentication attempts to systems the agent has never accessed before. Auto-revocation in this case is time-critical — every second the compromised agent runs, the attacker has access to your systems.
Regulatory non-compliance is specific to regulated industries. An agent has begun making decisions that would constitute regulatory violations — trades that look like market manipulation, credit decisions that exhibit discriminatory patterns, AML screening that is systematically missing specific transaction types. The compliance team identifies the pattern before a regulator does. Revocation halts the accumulation of non-compliant decisions while the underlying issue is diagnosed and remediated.
Each of these failure modes has a different detection profile, but they all require the same response capability: the ability to revoke the agent's authority to act, quickly, specifically, and with evidence.
Why Speed Matters: The <60 Second SLA
When people hear "auto-revocation in under 60 seconds," the immediate question is whether that is fast enough. The answer depends on what your agent is doing.
For a trading agent executing at high frequency, 60 seconds of unchecked operation after a risk threshold breach could mean thousands of bad trades. But high-frequency trading systems typically have hardware-level circuit breakers at the execution layer that operate in milliseconds — the revocation system is a secondary control, not the primary one.
For most enterprise AI agent deployments — customer service agents, document processing agents, fraud screening agents, workflow automation agents — 60 seconds is extremely fast. These agents typically operate in minutes-to-hours timescales, not milliseconds. A revocation that completes in under 60 seconds means the agent is halted before it finishes its current task in most cases.
The specific architecture that enables sub-60-second revocation matters. Kakunin implements a circuit breaker pattern: when the risk score crosses 0.85, the revocation trigger fires immediately and propagates to the CRL update within seconds. Your gateway, which is checking certificate status on every request, sees the revocation status within the next poll cycle. The SLA of under 60 seconds covers the full chain from threshold breach to the moment the next request from the revoking agent is rejected at the gateway.
The SLA documentation specifies the exact latency guarantees for each step in this chain. For on-call engineers, the DevOps operational documentation includes the full incident runbook for handling revocation events.
The Pre-Warning Architecture: 0.75 Before 0.85
One of the design decisions that distinguishes thoughtful revocation architectures from crude ones is the pre-warning threshold.
Automatic revocation without any warning creates operational disruption even when it is working correctly. An agent that gets revoked silently, without any pre-warning, leaves the operations team scrambling to understand why a service suddenly stopped. The investigation window is compressed. If it turns out to be a false positive — legitimate high-load operation that spiked the risk score temporarily — the remediation takes time and creates unnecessary downtime.
The 0.75 pre-warning threshold is designed to give your team time to investigate before auto-revocation triggers. When an agent's risk score crosses 0.75, Kakunin generates a risk.warning notification. Your on-call engineer gets paged. They have time to look at the event stream, assess whether the elevated risk reflects a genuine problem or a legitimate operational anomaly, and either take manual action or clear the alert if it is a false positive.
If the risk score continues climbing to 0.85 — meaning the anomaly is not transient and has not been addressed — auto-revocation fires. At this point, the engineer has already been briefed, understands the context, and can respond efficiently.
The notification is delivered as a webhook event (risk.warning) to your configured webhook endpoint. The payload includes the agent ID, current risk score, score trajectory over the past 24 hours, and the top contributing event categories. This gives your engineer the context they need to make a rapid assessment without having to query multiple systems.
For details on configuring webhook delivery and the event payload schema, see the webhooks documentation.
Manual Override: The Kill Switch
Auto-revocation handles the automated case. But there are scenarios where the appropriate response is immediate manual revocation, without waiting for a risk threshold to be crossed.
A customer support team member receives information indicating that an agent has been making promises it is not authorised to make. A security team identifies a prompt injection attack in progress. A compliance officer gets a call from a regulator asking about specific transactions. In each case, the right response is to halt the agent now, not wait for the risk score to catch up.
Kakunin's API includes a manual revocation endpoint (POST /api/v1/agents/{id}/revoke) that accepts a revocation reason code and immediately initiates the same revocation chain as auto-revocation. The certificate is invalidated, the CRL is updated, and the audit log records the manual revocation with the actor who initiated it and the reason code they provided.
The reason code is important. Under MiCA Article 72, the reason for revocation must be recorded and preserved. Kakunin's revocation reason taxonomy includes:
security_incident— credential compromise or suspected attackbehavioural_anomaly— risk score breachregulatory_compliance— compliance violation identifiedoperational_error— agent misconfiguration or bugmanual_review— precautionary halt pending investigationcertificate_expired— natural end of validity window
Each reason code triggers specific downstream actions in the audit system. A security_incident revocation, for example, automatically generates a security incident record with a timestamp, the actor who triggered the revocation, and the event context that preceded the revocation decision.
Enforcing Revocation at the Gateway
Revocation is only meaningful if it is enforced. An agent whose certificate has been revoked must be prevented from executing further operations. This enforcement has to happen at the network layer, not the application layer.
The reason application-layer enforcement is insufficient is that it requires every application the agent touches to check the revocation status. In a real deployment, an agent may interact with dozens of internal and external systems. Getting every one of them to check a revocation status API introduces latency, coupling, and — most importantly — a long tail of systems that might be missed.
Gateway-level enforcement solves this. Your API gateway is the single entry point for all agent traffic. When the gateway verifies the agent's X.509 certificate on every request (via mTLS), a revoked certificate fails the TLS handshake before any application code runs. The agent's request never reaches your services.
Kakunin's public verification endpoint (GET /api/v1/verify/{cert_serial}) is designed for gateway integration. It responds in under 500ms p99, is globally cached at the CDN edge, and requires no authentication. Your gateway can poll this endpoint on a configurable TTL — for most use cases, checking every 30–60 seconds balances freshness against request overhead.
For environments where even a 30-second staleness window is unacceptable, the CRL endpoint (GET /api/v1/crl) provides a complete list of revoked certificates that can be locally cached and refreshed at any frequency. This is the pattern used by high-frequency trading systems that cannot tolerate any propagation delay.
The certificate enforcement documentation covers gateway integration patterns for common API gateway platforms including Kong, Nginx, and AWS API Gateway.
Rebuilding Trust After Revocation
Revocation is not the end of the story. Once an agent is revoked, there is a recovery path for agents that were halted due to false positives or repairable issues.
The process mirrors the initial registration. The operator:
1. Investigates the cause of the revocation (using the audit trail and event history)
2. Remediates the underlying issue (updates the agent code, fixes the configuration, patches the security vulnerability)
3. Re-registers the agent, which issues a new certificate with a fresh 365-day validity window and a new serial number
4. Deploys the updated agent with the new certificate
The old certificate cannot be "un-revoked." Revocation is permanent. The new certificate is a clean slate, with a fresh audit trail that references the previous agent's identity. This is not a limitation — it is a design property. Permanent revocation means the historical record is clear: this certificate was revoked on this date, for this reason. The new certificate is a new identity, with a new history.
This is consistent with the trust model that regulators expect. An agent that was halted due to a security incident and then re-deployed with the same certificate would create ambiguity about whether the incident was fully remediated. A new certificate removes that ambiguity.
The agent re-registration documentation covers the full recovery workflow.
The Regulator's View of Auto-Revocation
From a regulatory perspective, auto-revocation addresses one of the core concerns about autonomous systems: who is responsible when something goes wrong?
In a human organisation, if an employee begins behaving in ways that threaten the firm or its clients, the firm has a duty to act — to investigate, to suspend the employee, and if necessary to terminate their authority to act. The speed and decisiveness of that response is itself a compliance signal: a firm that allows a bad actor to continue operating for months after becoming aware of a problem has a compliance problem.
The same logic applies to AI agents. An organisation that can demonstrate it had a system in place to detect anomalous behaviour and halt agents within 60 seconds of a threshold breach is in a very different compliance position from one that discovered a misbehaving agent only after a regulator flagged it.
The EU AI Act specifically contemplates the ability of operators to intervene in AI system operations as part of the human oversight requirements in Article 14. Auto-revocation is the technical implementation of that oversight capability: you are not relying on a human to notice something is wrong and then decide to act — you have automated the detection and response while preserving the human's ability to override.
For compliance officers building the evidence package for an EU AI Act compliance assessment, the /for-compliance-officers page maps each compliance requirement to specific system capabilities and audit evidence.
Building the Safety Architecture
Autonomous systems operating in regulated environments need safety architectures that are proportionate to the risk they carry. An AI agent that recommends movie content has a different risk profile than one executing financial transactions or making medical triage decisions.
The common element across all high-stakes AI agent deployments is this: you need a defined response when something goes wrong, and you need it to be fast, specific, and well-documented. Auto-revocation backed by cryptographic identity and a WORM audit trail provides that.
The organisations building this infrastructure now are not just reducing regulatory risk. They are building the institutional capability — the muscle memory — for managing autonomous systems responsibly. As AI agents take on more significant roles, that capability will be the differentiator between organisations that scale AI safely and those that discover the limits of unmanaged autonomy through incident, rather than design.
---
Kakunin provides auto-revocation in under 60 seconds when AI agent risk score exceeds 0.85. Pre-warning notifications at 0.75. Manual kill switch via API. See how DevOps teams use Kakunin or view the enforcement documentation.