Every production AI agent has a lifespan. Not because AI systems age or wear out, but because the context in which they operate evolves — the regulatory environment changes, the system's capabilities expand, the team responsible for it turns over, and the assumptions baked into its original design may no longer hold.
The 365-day certificate validity window in AI agent compliance infrastructure is not an arbitrary bureaucratic requirement. It is a forcing function that ensures organisations revisit each agent's authorisation at least once a year. It creates an annual compliance cycle that, done well, makes AI agent operations more robust, more auditable, and more aligned with the regulatory expectations that are tightening across regulated industries.
This is a practical guide to what the annual AI agent compliance cycle should look like, why it matters, and how to manage it at scale without creating an operational burden.
The 365-Day Requirement and MiCA Article 70
MiCA Article 70 specifies that certificates used to authenticate algorithmic trading systems must have a defined validity period. The standard that Kakunin implements — and that aligns with the emerging industry norm — is 365 days from the date of issuance.
The 365-day window is a balance between two competing needs. Certificates need to expire frequently enough to force regular review and key rotation, but not so frequently that renewal becomes a constant operational burden. Annual renewal aligns with the review cadences that most regulated organisations already have for other compliance activities: annual model validation reviews, annual penetration tests, annual risk assessments.
It is also worth noting what 365 days means in practice for certificate expiry. A certificate issued on January 15, 2026 expires on January 14, 2027. If your agent is still in production on January 15, 2027, it will be operating with an expired certificate. Depending on your gateway configuration, this might mean the agent is rejected by the gateway (desirable outcome, if you have a renewal process in place) or that it continues operating with an expired certificate (undesirable outcome that creates compliance exposure).
The operational challenge, which we will address in detail below, is managing renewals at scale across a fleet of agents with staggered expiry dates.
What Certificate Expiry Actually Means
When an X.509 certificate expires, it does not automatically stop working. The certificate is still cryptographically valid — the signature is still good, the public key is still the same. What changes is the semantic validity: a certificate that is past its notAfter date is considered expired and should not be trusted.
Well-configured gateway verification will reject expired certificates. Kakunin's verification endpoint returns status: "expired" for certificates past their notAfter date. If your gateway checks the certificate status on every request, an agent with an expired certificate will be rejected at the gateway.
If your gateway does not check expiry — either because it does not check certificate status at all, or because it caches statuses with very long TTLs — an expired certificate may continue to be accepted. This is not good practice. From a compliance perspective, an agent operating with an expired certificate has been operating outside its authorised validity window. Under MiCA Article 70, this is a compliance violation.
The practical recommendation: configure your gateway to check certificate status on every request (or with a short TTL cache), and configure expiry monitoring to alert your team when any certificate is within 30 days of expiry. This gives you a month to complete the renewal process without operational disruption.
The Annual Review: What to Assess
The 365-day renewal is not just a technical certificate refresh. It should be accompanied by a substantive review of each agent's compliance posture. This is the value of the forcing function: it ensures that agents do not continue operating indefinitely on assumptions that are no longer current.
The annual review should address six questions.
Is the agent's scope still appropriate? When the agent was first registered, its scope was defined — what systems it could access, what actions it could take, what data it could read. Over the past year, has the team expanded the agent's access informally (granting it access to new data sources without updating the formal scope definition)? Has the business context changed in ways that should narrow the agent's scope? The renewal is the right moment to formally align the certificate's documented scope with the agent's actual operational parameters.
Has the regulatory environment changed? MiCA, the EU AI Act, and related regulations are evolving. New guidance is issued, interpretations are clarified, and new obligations come into effect. The annual review should include a brief regulatory horizon scan: are there new requirements that apply to this agent that did not apply a year ago? Do any recent enforcement actions suggest that the regulator interprets existing requirements differently than your current compliance posture assumes?
Is the risk scoring model still calibrated? Over 12 months of production operation, the agent's behavioural baseline has been well-established. Is the risk scoring calibration still appropriate? Have there been false positive alerts that suggest the thresholds are set too tight? Have there been incidents that suggest thresholds should be tightened? The annual review is the right time to revisit threshold settings.
Has the team responsible for the agent changed? Agent compliance is not just technical infrastructure — it requires human ownership. Someone needs to monitor the risk score alerts, respond to incidents, and manage the regulatory relationship. If the team responsible for a given agent has turned over, the new team members need to be briefed on the compliance requirements and the operational procedures.
Are the response procedures still documented and current? The incident runbooks — what to do when the risk score hits 0.75, how to investigate a potential compromise, who to notify if the agent needs to be revoked — need to be current. Runbooks that were written 12 months ago may reference team members who have left, systems that have been replaced, or procedures that have been superseded.
Is the agent still necessary? A genuinely useful annual review question is whether each agent should still be in production at all. AI agents that were launched as experiments, that have been superseded by newer capabilities, or that are no longer serving their original purpose should be formally decommissioned rather than quietly abandoned. An agent that continues running in production with no active owner is a compliance liability.
Managing Renewal at Scale: The Fleet Perspective
Individual certificate renewal is straightforward. Managing renewals across a fleet of 50, 100, or 500 agents with staggered expiry dates is an operational challenge.
The core principle is to not allow renewals to pile up. If all your agents were registered around the same time, all their certificates will expire around the same time. A fleet of 100 agents all expiring within a two-week window creates a concentrated renewal workload that is difficult to manage carefully and creates pressure to cut corners on the substantive review.
The solution is staggered registration. When registering a new batch of agents, spread the registration dates across a 60-day window so that renewals are distributed throughout the year. This converts the annual renewal crunch into a steady-state process of three or four renewals per week.
Kakunin's dashboard provides an expiry calendar view showing all certificates by expiry date, allowing fleet managers to see their upcoming renewal workload. Agents expiring within 30 days are flagged automatically, and a certificate.expiring_soon webhook event fires 30 days before expiry for each agent.
The webhooks documentation covers the configuration for renewal notification webhooks, including the event payload structure and the recommended 30-day advance notice setting.
The Technical Renewal Process
From a technical standpoint, certificate renewal follows the same process as initial registration, with one significant difference: the renewal creates a new certificate with a new serial number, but it explicitly references the previous certificate in the audit trail, maintaining continuity of identity across the renewal.
The renewal process:
1. The operator calls POST /api/v1/agents/{id}/renew
2. Kakunin creates a new KMS key for the renewed agent (key rotation at every renewal)
3. A new X.509 certificate is issued with a new serial number, new validity window (365 days from renewal date), and the new key
4. The previous certificate is marked as expired in the audit log
5. The new certificate is returned in the response and the new KMS key ARN is stored in the database
6. The agent resumes operation using the new certificate
The key rotation at every renewal is important. Even if the previous key was never compromised, rotating it annually limits the window of exposure if a compromise is discovered retrospectively. An attacker who obtained a copy of a private key that has since been rotated can only impersonate the agent during the period when that key was active.
The certificates documentation covers the renewal API in detail, including the specific fields in the renewal response and the transition procedure for updating deployed agents with the new certificate.
Decommissioning: The Other End of the Lifecycle
Certificate renewal assumes an agent that is still in production and still warranted. But the annual review also surfaces agents that should be decommissioned.
Decommissioning an AI agent involves more than just stopping the process. For compliance purposes, it requires:
1. Revoking the agent's certificate (using the security_incident or operational_error reason code depending on why it is being decommissioned)
2. Documenting the decommissioning decision and rationale in the audit log
3. Preserving the agent's historical audit trail for the retention period required by your applicable regulations (five years under MiCA Article 75)
4. Removing the agent from your monitoring systems and alerting configurations
5. Updating any documentation that references the agent's capabilities or the services it supports
The WORM audit log means you cannot simply delete the historical record. Decommissioned agents' audit trails are retained in append-only storage, accessible for regulatory inquiry during the retention period, but no longer generating new events.
For agents that were operating under MiCA, GDPR, or EU AI Act obligations, the decommissioning should be documented in the records of processing activities maintained under GDPR Article 30. The regulator should be notified if the agent was subject to specific regulatory authorisations that require notification of withdrawal.
Building the Annual Compliance Calendar
For regulated organisations operating AI agent fleets, the annual compliance cycle should be a planned, resourced activity — not an emergency triggered by expiry notifications.
The annual compliance calendar for AI agent management includes:
30 days before expiry: Automated notification (webhook). Assign the renewal to a responsible team member. Schedule the substantive review.
21 days before expiry: Complete the substantive review (scope, regulatory horizon, risk calibration, team, procedures, necessity). Document findings.
14 days before expiry: Complete any remediation required by the substantive review (update scope definitions, update runbooks, transfer ownership if team has changed).
7 days before expiry: Complete technical renewal. New certificate issued and deployed to agent. Verify the agent is operating correctly with the new certificate.
Day of expiry (if renewal not yet complete): Gateway rejects the agent. This is the backstop — the operational consequence of missing the renewal. Having this backstop means that expired certificates cannot silently continue operating; they fail loudly, creating pressure to complete the renewal.
The gap between the 7-day technical renewal and the actual expiry is a buffer for unexpected issues. If the technical renewal fails for some reason — a misconfiguration, an API error, a key rotation problem — there is a week to diagnose and resolve before the agent actually expires.
For compliance officers overseeing AI agent fleets, the /for-compliance-officers page covers the compliance calendar management tools and the dashboard views that support fleet-wide renewal oversight.
The Renewal Record in the Audit Trail
From a compliance perspective, the renewal record is a significant audit trail event. It documents:
- The agent's continued authorisation under the renewed certificate
- The team member responsible for approving the renewal
- The date of the substantive review
- Any scope changes made at renewal time
- The new certificate serial number and the previous certificate it replaces
This record is relevant both for internal governance (the annual review demonstrates that the organisation is actively managing its AI agent fleet) and for external regulatory inquiry (the renewal history shows the regulator that certificates are being actively managed, not passively allowed to lapse).
The renewal record is stored in Kakunin's WORM audit log alongside the original registration and all operational events. When a regulator requests the full audit trail for an agent, the renewal history is included.
---
Kakunin issues 365-day X.509 certificates for AI agents, aligned with MiCA Article 70. Automated expiry notifications 30 days before expiry. Full audit trail linking renewals to preceding certificate history. Read the certificates documentation or explore the compliance officer workflow.