This might be harsh, however this is risky and wrong at many levels, the lack of experience makes it even harder to understand whats missing and gives a false impression of confidence. Your ISO27001 and SOC2 compliance becomes questionable at this point and in turn you bubble up this concern all the way up to your customers if you are supporting them as a vendor (Ideally thats how these compliances work)
OIDC is generally meant for authentication, however it does not stops you from doing what you want to experiment, of-course you can overload it with claims in which case you are using it for authorization
How the OIDC token is obtained is most important here, one can use clientSecret for secured clients, however in the absence of secret it heavily relies on redirect URI for security mechanism, nounce and PKCE token to avoid replay and forgery
Calling your product as RelyingParty does not makes you RP in in real sense, the workload is the RP here. Overloading the audience claim allows you to become secondary RP, however this opens up gates for whole different kind of challenges and explicit configuration.
You are vulnerable to replay, MITM and more.
The company names notion, gusto and cursor as its customers, not sure in what capacity they use but it does brings up this interesting concept of building your skyscraper on a footing developed by some one else without verifying
Ugh. OIDC’s whole trust model assumes the subject of the token is the responsible party. Sounds like you are opening a door for a future security problem.
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.
I find their post to be a little light on details, but my read is that they're essentially doing what you're complaining they should.
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".
Isn't this what things like CIBA is supposed to address? You still need to do some work, and one could argue that the issue isn't really new, just that we're too lazy. Agentic systems just shifts the focus of where the problem is to where it should be: The role had too wide permissions for the task at hand.
just relating my personal/professional setup, I run Pocket ID for myself and made an agent account for claude. I have it set up with limited access policies to pre-prod Cloudflare resources and Tailscale servers for occasional tasks. I really like the control I have over access, grant it just when it’s needed and only exactly as much as needed. I wish SSO didn’t require biz/enterprise plans on so many services so I could use my OIDC in more ways
This might be harsh, however this is risky and wrong at many levels, the lack of experience makes it even harder to understand whats missing and gives a false impression of confidence. Your ISO27001 and SOC2 compliance becomes questionable at this point and in turn you bubble up this concern all the way up to your customers if you are supporting them as a vendor (Ideally thats how these compliances work)
OIDC is generally meant for authentication, however it does not stops you from doing what you want to experiment, of-course you can overload it with claims in which case you are using it for authorization
How the OIDC token is obtained is most important here, one can use clientSecret for secured clients, however in the absence of secret it heavily relies on redirect URI for security mechanism, nounce and PKCE token to avoid replay and forgery
Calling your product as RelyingParty does not makes you RP in in real sense, the workload is the RP here. Overloading the audience claim allows you to become secondary RP, however this opens up gates for whole different kind of challenges and explicit configuration.
You are vulnerable to replay, MITM and more.
The company names notion, gusto and cursor as its customers, not sure in what capacity they use but it does brings up this interesting concept of building your skyscraper on a footing developed by some one else without verifying
Ugh. OIDC’s whole trust model assumes the subject of the token is the responsible party. Sounds like you are opening a door for a future security problem.
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.
I find their post to be a little light on details, but my read is that they're essentially doing what you're complaining they should.
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".
Isn't this what things like CIBA is supposed to address? You still need to do some work, and one could argue that the issue isn't really new, just that we're too lazy. Agentic systems just shifts the focus of where the problem is to where it should be: The role had too wide permissions for the task at hand.
just relating my personal/professional setup, I run Pocket ID for myself and made an agent account for claude. I have it set up with limited access policies to pre-prod Cloudflare resources and Tailscale servers for occasional tasks. I really like the control I have over access, grant it just when it’s needed and only exactly as much as needed. I wish SSO didn’t require biz/enterprise plans on so many services so I could use my OIDC in more ways
Very bad idea and is just asking for the agent to breached itself via a bad prompt.