AI Actor Registration and Identity Binding

An AI Actor's identity can enter the catalog two ways: an operator registers it up front (confidence_state: curated), or the platform notices it from traffic and materializes it on its own (confidence_state: observed). This capability covers both paths and the role-based side of identity — it is marked partial because the observed-actor half stops at visibility today: nothing downstream actually enforces the approve/block decision yet.

Role sync pulls role definitions from the tenant's identity provider — only Auth0 is implemented; Cognito, Okta, and Entra are registered as drivers but return "not implemented" if called — on a 15-minute background timer plus a manual sync button, and upserts them keyed by (source, source_id) so a role's UUID (and any policy bindings that reference it) survives a rename. Role Mappings then defines the rule that turns an incoming claim — an OIDC group, an Azure AD claim, a SAML attribute — into one of those synced roles, by exact match or another configured strategy, and can be tested against a sample claim set before saving.

Observed actors come from a different path entirely: a reconciler scans the last 24 hours of invocations every 60 seconds for subject identities that show up in traffic but have no matching row in the actor catalog, and only for invocations whose subject type is agent or service — a human calling an MCP directly under their own identity is never turned into an actor row. A new observed actor gets a synthesized name from its identity hash and starts stabilized: false; an operator can Approve it (moves it to approved) or Block it (moves it to blocked, and blocked actors are excluded from all future reconciliation passes so they don't reappear). As the code comments on this flow say plainly: the approve/block state is advisory until a later phase wires it into enforcement — blocking an observed actor today changes its label, not what it can do.