In early 2025, a financial regulator in an EU member state received a complaint about an AI agent deployed by a regulated FinTech. The complaint alleged the agent was executing trades outside its authorised scope — a MiCA compliance violation. The regulator's first step was to contact the FinTech and request the agent's compliance documentation.
The FinTech's response took three days. It involved multiple back-and-forth exchanges, a manual export of log data, and a PDF assembled by the legal team. The information was eventually provided, but the regulator noted in their written response that the delay and the manual process raised questions about the organisation's monitoring capabilities.
This scenario will become more common as AI agent deployments scale and as regulatory capacity for supervising them grows. The question for organisations deploying AI agents is: when your regulator comes asking, how quickly and how independently can you give them what they need?
The Verification Problem from the Regulator's Perspective
Regulators have a specific verification need that is different from the operator's internal monitoring. They need to be able to confirm:
1. That a specific AI agent existed and was authorised to operate at a specific time
2. That the agent's authority was granted by a legitimate process with documented oversight
3. Whether the agent's authority is currently valid or has been revoked
4. What the agent's operating history looked like during the period under investigation
The challenge is that today, most of this information sits inside the operator's systems. The regulator is entirely dependent on the operator's cooperation and the operator's data. If the operator has incentives to be selective about what it shares — as any regulated entity facing enforcement inquiry might — the regulator has limited independent verification capability.
This asymmetry is a fundamental problem in AI agent regulation. The EU AI Act recognises it explicitly in Articles 73 and 75, which require that monitoring information be "accessible" to competent authorities. But accessibility without independence is limited: an authority that must ask the regulated entity for access to data has weaker oversight than one that can independently verify key facts.
Public Verification Endpoints: Independence Without Credentials
The architecture that resolves this asymmetry is public verification endpoints — API endpoints that any party, including regulators, can query without authentication and without the operator's involvement.
Kakunin operates three such endpoints.
The certificate verification endpoint (GET /api/v1/verify/{cert_serial}) allows anyone with a certificate serial number to check the certificate's validity status, issuer, subject, and validity window. The response includes whether the certificate is currently active, revoked, or expired, and if revoked, the revocation timestamp and reason code. No authentication. No API key. No dependency on the operator.
The Certificate Revocation List endpoint (GET /api/v1/crl) provides the full list of revoked certificates in the Kakunin system. A regulator conducting a retrospective investigation can download this list and cross-reference it against any certificates they are investigating. The list is updated in real time as revocations occur, with a p99 response time under 300ms.
The health endpoint (GET /api/v1/health) confirms that the verification infrastructure is operational. For regulatory audits that require confirming the availability of compliance systems at a specific time, this endpoint provides a timestamped availability proof.
These endpoints are described in detail on the /for-regulators page, which is specifically designed to give regulatory and audit teams the technical documentation they need to use the verification infrastructure.
What a Regulator Actually Does With This
The practical verification workflow for a regulator or auditor investigating an AI agent looks like this.
Step 1: Obtain the certificate serial number. This comes from the regulated entity, from the complaint that initiated the investigation, or from a transaction record that includes the agent's certificate reference. The certificate serial number is included in every signed transaction that Kakunin-certified agents produce.
Step 2: Query the verification endpoint. The regulator calls GET /api/v1/verify/{cert_serial}. The response, which arrives in under 500ms, includes the full certificate metadata: issuer, subject (which includes the agent identifier and the operator's organisation), validity window, current status, and if revoked, the revocation details.
At this point, the regulator has independently verified: this agent existed, was registered under this organisation, was authorised to operate during this period, and is currently in this status. This information required no cooperation from the regulated entity.
Step 3: Check revocation history. If the investigation involves a period during which the agent might have been revoked, the regulator downloads the CRL and cross-references the certificate serial. The CRL includes revocation timestamps and reason codes for all revoked certificates, allowing the regulator to determine whether the agent was operating under a valid certificate during the period in question.
Step 4: Request the full audit trail. For a detailed investigation, the regulator requests the full audit trail export from the regulated entity. This is the point where operator cooperation is required — but the regulator now has an independent baseline to compare against. If the operator's provided audit trail does not match the certificate validity information that the regulator independently verified, that discrepancy is itself significant.
The No-Authentication Design Choice
The decision to make verification endpoints public — no API key, no registration, no authentication — is deliberate and important.
An authentication requirement would undermine the independence of verification. If a regulator needs to register for an API account before they can verify a certificate, several problems arise: account provisioning takes time, creating friction that slows investigations; the account creation process gives the operator visibility that an investigation is occurring; and the access control layer becomes a potential point of failure or manipulation.
A public endpoint has none of these problems. Anyone can query it. Regulators, auditors, counterparties, journalists investigating AI accountability stories, researchers studying AI deployment patterns — all can verify a certificate's status without asking anyone's permission.
This is the same principle that makes the public web's certificate infrastructure work. When your browser verifies an HTTPS certificate, it does not need to authenticate to the CA. The CA's Certificate Revocation List is publicly accessible. Anyone can check whether a certificate is valid. This public verifiability is what makes the system trustworthy.
The rate limit — 1,000 requests per minute per IP — prevents abuse while preserving open access for legitimate use cases. A regulator conducting an investigation will not come close to this limit.
The Audit Trail Export: When Independence Is Not Enough
Public verification endpoints confirm the existence, identity, and current status of an AI agent. They do not provide the granular operational history that a detailed investigation requires.
For that, regulators request the full audit trail export from the regulated entity. This export, which Kakunin produces in JSON or CSV format, includes:
- Agent registration record (who registered the agent, when, with what parameters)
- Certificate issuance record (certificate metadata, KMS key ARN, issuance timestamp)
- Full behavioural event log (every event captured during the investigation period, with timestamps and cryptographic linkage to the agent identity)
- Risk score history (the risk score trajectory over the investigation period, with the specific events that drove each score change)
- Revocation record if applicable (revocation timestamp, reason code, actor who initiated revocation)
The WORM nature of Kakunin's audit log means this export is tamper-evident. The regulated entity cannot selectively delete inconvenient events from the audit log — the PostgreSQL rules that enforce append-only semantics make this impossible. The regulator can be confident that the exported audit trail represents the complete historical record.
For compliance officers preparing for regulatory inquiries, the /for-compliance-officers page describes the specific documentation and export capabilities that support regulatory response.
Latency Requirements: Why <500ms Matters
Verification endpoints that are slow are verification endpoints that do not get used. Regulators and auditors conducting investigations are often under time pressure — they have multiple cases, limited staff, and regulatory deadlines. If a verification API takes 5 seconds to respond, it quickly becomes a bottleneck.
Kakunin's verification endpoint has a p99 latency SLA of under 500ms. This is the 99th percentile — meaning that 99 out of 100 requests, even under peak load, will complete in under 500ms. This is fast enough to integrate into interactive workflows without creating friction.
The sub-500ms performance is achieved through CDN caching. Certificate status is cached at CDN edge nodes globally, so verification requests do not need to traverse to the origin for every query. The cache TTL is short enough to propagate revocations promptly (the CRL is updated within seconds of a revocation, and cached responses reflect the latest status within one cache TTL period).
Framework Compliance: How the Verification Architecture Maps to Regulations
The public verification infrastructure maps to specific regulatory requirements across multiple frameworks.
MiCA Article 73 requires that monitoring mechanisms allow competent authorities to verify that algorithmic trading systems are operating as intended. The certificate verification endpoint provides exactly this capability: a competent authority can independently verify a system's identity and status.
MiCA Article 75 requires audit trail accessibility. The WORM audit log and export capability satisfy this requirement.
EU AI Act Article 73 (human oversight mechanisms) requires that high-risk AI systems can be monitored and their operations reviewed. The public verification endpoint and the audit trail export together satisfy this requirement.
GDPR Article 30 (records of processing activities) requires that records be available to the supervisory authority upon request. The audit trail export capability satisfies this requirement for AI processing activities.
The detailed framework compliance mapping is available in the concepts documentation, which maps each regulatory requirement to specific system capabilities and provides the evidence structure for compliance documentation.
Building the Regulator Relationship
There is a strategic dimension to public verification capability that goes beyond compliance. Organisations that proactively make their AI agent compliance infrastructure available to regulators — rather than treating every regulatory interaction as an adversarial process — build a different kind of regulatory relationship.
Regulators have limited capacity. They must prioritise their supervisory attention. An organisation that makes independent verification easy, that proactively provides compliance documentation, and that demonstrates functioning monitoring and response capabilities is less likely to receive intensive supervisory attention than one that makes every interaction difficult.
This is not a guarantee of favourable treatment. But it is a material difference in the regulatory relationship that translates over time into a more predictable and less disruptive supervisory experience.
The ESMA guidelines on algorithmic trading include specific expectations about regulatory transparency for automated systems. Reviewing these guidelines alongside your compliance documentation is useful preparation for regulator dialogue.
The Independent Verification Advantage in Enterprise Sales
Public verification capability matters not just for regulators. Enterprise customers and counterparties increasingly require independent verification of the AI agents they are interacting with or depending on.
A bank that is considering connecting to an AI agent service from a FinTech partner wants to know: can I independently verify that this agent is authorised, that its certificate is valid, and that it has not been revoked? With Kakunin, the answer is yes — they can query the verification endpoint with the agent's certificate serial and get an authoritative response in under 500ms. They do not need to trust the FinTech's assurances. They can verify independently.
This independent verifiability transforms the AI agent trust model from "trust the operator" to "verify the certificate." It is the AI agent equivalent of HTTPS: you do not trust a website because its operator told you it was secure — you verify the certificate.
---
Kakunin provides public no-auth verification endpoints for AI agent certificates. GET /api/v1/verify/{cert_serial} returns certificate status in <500ms. No registration required. Explore the verification API documentation or read the regulator overview.