AI Actors

"Actor" is not one database table — it is four: agents, model versions, applications, and identity roles, each with its own list route and its own shape, brought together under one catalog surface. Agents are the actively-behaving kind: a row carries a framework hint, an optional API key (fab_ak_-prefixed, SHA-256-hashed at rest, shown to the operator exactly once at generation time), and the list of IdP role names the gateway writes into the request context at key-resolution time so role-bound policies fire on agent traffic the same way they fire on a human call carrying a JWT.

Not every agent row is registered the same way. A curated agent is one an operator added by hand through "Register AI Actor." An observed agent is one the platform inferred from live traffic — an X-MCP-Agent-ID header, a telemetry reconciliation pass, or (once wired) an MCP initialize packet — and it stays in that unvetted state until an operator explicitly approves or blocks it. claimed_identity holds whatever the runtime asserted about itself and is never trusted on its own; verified_identity holds what has actually been checked. Deleting an observed or blocked agent also purges its underlying invocation rows so the reconciliation job can't re-materialize it on the next pass — curated and approved agents keep their invocation history because it stays audit-relevant.

Roles, models, and applications are simpler and carry no confidence lifecycle. A role is a normalized identity synced from an external source system, recording which system and which source-side role ID it came from. A model version is an immutable snapshot identified by a SHA-256 hash, optionally linked back to the MCP server that exposed it. An application is a runtime client identity carrying an SSO client ID and an owner email. All three are reachable from this surface and can be the subject of a policy exactly like an agent can.

An actor's detail page pulls its recent activity from the same place policy enforcement logs live: it looks up recent decisions for that subject, then derives which MCP servers and tools appear in those decisions to show what the actor has actually touched. It is a view over enforcement history, not a separate activity log kept by the catalog itself.