Governing AI agents
An AI agent is not a new kind of object in this platform. It is an identity — one that happens to act without a person at the keyboard — governed by the same ownership, attestation and access machinery as every other non-human identity.
The boundary first: what is governed here is the identity an agent uses, not the agent's behaviour. Nothing here stops a program from running; it decides whether the identity that program authenticates as is known, owned, current and revocable.
What makes an agent an agent
An agent is an identity of type ai_agent, so every non-human control already
applies: ownership resolution, the orphan inbox, blast-radius, emergency lockout,
reconciliation. On top of it sits a one-to-one agent profile carrying what
only makes sense for an agent — a purpose in prose, an autonomy tier (how
much human oversight sits between the agent and each act), the platform it lives
on and its identifier there, and optionally the person or team it acts for.
That last field is the clearest difference from a service account: a service account runs a job, an agent acts on someone's behalf, and the model records whose. Purpose, latitude and named principal are three facts a service account has no field for.
Provenance is enforced, not decorative
Every agent record says where it came from, and that field cannot be talked into
saying something else. Discovered means a platform sync actually saw the
object — today that is Microsoft Entra's agent surface, where the connector reads
the configured agents object during its normal sync and each record becomes an
ai_agent identity, marked discovered and stamped with the platform's own
identifier. It rides the sync that already runs rather than being a separate
action. Registered means a human declared it: the intake path for a
self-hosted agent no platform can see, honest about being a declaration.
The two cannot be conflated. A profile's editable surface is exactly three fields — purpose, autonomy tier and the acts-for link. An attempt to set the source, the platform or the external identifier is rejected outright rather than quietly dropped, because a declared agent rendering as "discovered" would turn an assertion into evidence. The rule runs the other way too: a later sync refreshes provenance only. It will fill an empty purpose, but never overwrites a purpose, tier or acts-for link a human asserted — upstream config changes for reasons that have nothing to do with who accepted accountability here.
Ownership: filled from the sponsor, never overwritten
Where the platform carries a sponsor — the human it holds accountable for the agent — discovery imports that as the agent's owner, fill-only: one explicit ownership record, written only when no owner exists yet. An owner a human set is never replaced by a later sync, and an agent whose sponsor is unreadable or ambiguous gets no owner row at all; it surfaces as unowned and flows into the normal claim process. That last part is load-bearing: a placeholder owner would raise ownership coverage without raising accountability, and coverage that counts fictions is worse than a visible gap.
Autonomy tiers and the attestation ladder
Three autonomy tiers are recorded per agent: assisted (a human in the loop for every act), supervised (the agent acts, a human reviews) and autonomous (the agent acts unattended). The tier is not a badge — it selects how often the agent is re-confirmed, through seeded certification rules evaluated in priority order:
| Tier | Re-attested every |
|---|---|
| Autonomous | 90 days |
| Supervised | 180 days |
| Assisted | 365 days |
| Agent with no profile | 365 days |
The less human oversight there is per act, the more often accountability is
re-confirmed. The fourth row is not filler: an ai_agent identity can
legitimately have no profile — a legacy record, or one created outside the intake
path — and without that floor it would fall through into the generic non-human
rule, which sits below all four and covers every other non-human identity yearly.
Each review asks whether the agent is still needed, still owned and still operating within its declared purpose. It routes to the target's manager as an ownership proxy, carries a 30-day grace period, and on expiry flags for review rather than revoking anything.
On the two tier numbers. The platform also classifies the whole non-human population on a four-rung ladder, derived from what kind of identity something is rather than from anything a human asserts, and the three autonomy tiers correspond to its first three rungs. The fourth — AI-to-AI, covering identities that delegate to other machine identities — is about delegation chains, not about how much oversight sits in front of an act, which is why no agent carries it as a setting. Three tiers, four rungs, one vocabulary, no contradiction.
Credential inventory: references, kinds and dates
The inventory answers "what does this agent hold, and when does it stop working" — the commonest cause of an agent failing in production being a client secret nobody rotated. It holds a reference (the credential's identifier at the source), its kind and its dates, and no secret material at all: there is no column that could carry any, because a third secret path hiding in an inventory table would be a third place a secret could leak from.
A daily sweep reads it from connectors declaring the capability, today Microsoft Entra (application-registration secrets and certificates) and Google Workspace (application-specific passwords). Findings are raised ahead of the date: expired, expiring within the window, and no expiry at all — the last a standing posture finding rather than an imminent outage, since such a credential can never be rotated by a deadline, only by a decision. None of them carries a one-click fix: we do not hold the secret, so the finding points at where rotation happens.
The other absence is treated the same way: an unknown last-use reads "not reported", never "never used". Reporting agent sign-in activity from Entra requires Workload ID licensing, and without it the platform has no evidence either way. Activity counts as reported only when a platform-discovered credential arrives carrying a real last-use date — traffic against RapidValue's own API does not count, being our log rather than the target's. Where the evidence is missing the product says so and names the licence requirement, rather than presenting silence as a clean bill of health.
The kill-switch composes; the release is deliberately asymmetric
When an agent misbehaves, one action stops the identity it uses — and it is not a new mechanism. It composes the existing emergency lockout, which suspends the identity, force-revokes every grant and disables every account across all connected systems, overriding each connector's normal drift policy; and it revokes the credentials RapidValue issued to that agent.
A reason is mandatory. The action is recorded as a critical event in the immutable audit log along with what was revoked and, importantly, anything that failed to revoke: partial failures are returned rather than swallowed, because a credential the platform could not revoke is exactly what an incident responder must be told about.
Release lifts the lock and nothing else. The identity becomes active again, accounts are re-enabled, and reconciliation restores the access the Expected state still justifies. The credentials stay revoked. That asymmetry is deliberate rather than a limitation to be fixed: the credential was revoked because it might have leaked, and a possibly-leaked secret should never return as a side effect of someone deciding the incident is over. Reissuing is a second, explicit act, and a reason is mandatory on release too.
Administrators and the security team can both use it — incident response should not wait for an administrator to be found — while releasing it is an administrator action.
Evidence
Registration, profile changes, kill-switch activation and release all land in the immutable, hash-chained audit log, and an evidence pack assembles the register, ownership coverage, credential currency, attestation history and that trail into one verifiable bundle (Evidence and signing). It states its own applicability rather than asserting compliance: the EU AI Act articles it cites bind deployers of high-risk AI systems, and identifying which of your agents qualify is your assessment to make, not ours.
Known edges, published rather than discovered
- This governs identities, not behaviour. Nothing here prevents an agent from executing.
- No behavioural baselines over external agent activity. Anomaly detection built on telemetry we do not own is deliberately not built, and no surface implies it is. What is reported is strictly first-party: a credential we issued reaching for a scope it was not granted (a recorded refusal, not an inference), and a granted scope first used long after issue. Neither resolves itself — "trim the grant", "widen it deliberately" and "we are compromised" are three conclusions from one fact.
- The kill-switch revokes the credentials we issued, not the ones we never hold. A client secret living in Entra is revoked in Entra. The lockout half still removes that agent's access through every connected system, and the audit record names whatever could not be revoked.
- Sign-in reporting depends on the source. Where a platform does not report workload sign-in activity, dormancy stays unknown rather than inferred.
- Per-tier cadence is not yet a tenant setting. The four rules are seeded and editable in the certification rule workbench like any other, but there is no dedicated tier-to-cadence control in governance settings.
- Coverage is what the connectors report. Agents on platforms with no connector, and credential kinds outside those named above — Google Cloud service-account keys, for instance — are not discovered. Registering one by hand is a declaration rather than a discovery, and says so.
Further reading: