OIDC is good when the end user needs short-term access validation and authorization. The claim and responsibilities of what they do are on that user. Now that you have agents involved, the user can just shrug it off, saying 'oh the AI went rogue'. You probably need a separate role for agent specific tasks that severely limits the access specific to your workload, but that is a work of its own.
They're mapping the identity back to "agent" instead of "person". With the optional ability for the agent to present an "agent:person" combo in cases where it was triggered by a person.
Some quotes that imply but don't actually technically clarify what I mean:
> we now had a way to treat each cloud agent session as its own identity
> Once the human approves, access is scoped to the cloud agent session ID and the specific database that was requested.
> Using OIDC, cloud agents can request and be approved for short-lived access as they would with databases above. Requests are always logged in Formal and attributed to both the cloud agent and the engineer that launched it.
It sounds like they're not just attesting that the agent is the person, they're always scoping to a new combined identity.
So there's no confusion over whether it was a person, an agent, or an agent started by a person. (however where you go from there for culpability is a different question...)
But it doesn't seem like there's a case where a person did a thing (with their own credentials) and can then point a finger at an agent as say "oh it went rogue".
We then have the ability to enforce (extremely fine grained) policies based on that combined identity, plus any of the claims in the OIDC token (e.g., the repo URL), plus any of the data on the protocol itself (e.g., block non-read-only queries; redact anything sensitive).
Pedantry alert: Private keys are secrets.
For us, most of our MCPs have non-undoable actions disabled. This is to stop agents writing a tool that recursively doing something silly.
We then have the ability to enforce (extremely fine grained) policies based on that combined identity, plus any of the claims in the OIDC token (e.g., the repo URL), plus any of the data on the protocol itself (e.g., block non-read-only queries; redact anything sensitive).