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".
Yes, exactly, a cloud agent always authenticates itself (via OIDC) as an agent (machine) identity, with the option for the identity of the human who launched it to ride along.
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).
The dogfooding example I read was basically agent asking for user to sign off on permissions, Nd taking over from that point on. It doesn’t exactly read any different than any other ‘AI went rogue stories.
I am saying it’s a slippery slope and OIDC was not necessarily designed for it.
But OIDC was pretty explicitly designed for this (at least the later versions) - The whole point is that you can configure an identity provider, and then outsource identity verification to that provider.
So sure - it wasn't designed with agents directly in mind, but it's supported workload identity federation for a while (and is used in this manner for lots of big players - github, GCP, AWS, Azure, etc...)
This just seems to extend that concept slightly to allowing the workload identity to be generated on the fly based on user/agent combinations, with a HITL addition to approve the identity being generated and grant it a subset of permissions.
---
What you're saying here is different than what you implied in the first comment.
There is a real and meaningful difference between
1. A user can blame a rogue agent for actions they [the user] performed
2. An agent itself went rogue
So sure - #2 is still a risk, and one they'd have to mitigate with the security controls they talked about (minimal access, temporary grants, HITL, etc). Frankly - #2 is always a risk. That's what "agents" are (both the bot and the fleshy kind). It's also why we have logging and visibility tools that should be recording what was done, by whom, and for what reason, along with robust backups. You can't really close this hole, you accept it, monitor it, and hold the agent to account (and again - I'm with you on discussing culpability for bots and what that means in the legal sense. Ex - do we charge the person who introduced the bot, the company running it, the party that injected bad context, etc...?)
But #1 is not a thing a person can do - they can't take malicious actions and then blame a rogue agent.
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.
This is exactly why you must not do that...
But an MCP with read-only scope is what you need. Not a limit in front of a write path, but read-only by construction. I use a MCP of my monitoring app for that (Maintenant), so LLM can inspect my stack easily.
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
As stated in the second paragraph of TFA, the machine workloads get their own infrastructure identity. Each identity can have different policies and permissions.
Yes, exactly, a cloud agent always authenticates itself (via OIDC) as an agent (machine) identity, with the option for the identity of the human who launched it to ride along.
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).
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".
Yes, exactly, a cloud agent always authenticates itself (via OIDC) as an agent (machine) identity, with the option for the identity of the human who launched it to ride along.
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).
https://docs.formal.ai/docs/guides/policies/introduction
The dogfooding example I read was basically agent asking for user to sign off on permissions, Nd taking over from that point on. It doesn’t exactly read any different than any other ‘AI went rogue stories.
I am saying it’s a slippery slope and OIDC was not necessarily designed for it.
But OIDC was pretty explicitly designed for this (at least the later versions) - The whole point is that you can configure an identity provider, and then outsource identity verification to that provider.
So sure - it wasn't designed with agents directly in mind, but it's supported workload identity federation for a while (and is used in this manner for lots of big players - github, GCP, AWS, Azure, etc...)
This just seems to extend that concept slightly to allowing the workload identity to be generated on the fly based on user/agent combinations, with a HITL addition to approve the identity being generated and grant it a subset of permissions.
---
What you're saying here is different than what you implied in the first comment.
There is a real and meaningful difference between
1. A user can blame a rogue agent for actions they [the user] performed
2. An agent itself went rogue
So sure - #2 is still a risk, and one they'd have to mitigate with the security controls they talked about (minimal access, temporary grants, HITL, etc). Frankly - #2 is always a risk. That's what "agents" are (both the bot and the fleshy kind). It's also why we have logging and visibility tools that should be recording what was done, by whom, and for what reason, along with robust backups. You can't really close this hole, you accept it, monitor it, and hold the agent to account (and again - I'm with you on discussing culpability for bots and what that means in the legal sense. Ex - do we charge the person who introduced the bot, the company running it, the party that injected bad context, etc...?)
But #1 is not a thing a person can do - they can't take malicious actions and then blame a rogue agent.
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.
This is exactly why you must not do that... But an MCP with read-only scope is what you need. Not a limit in front of a write path, but read-only by construction. I use a MCP of my monitoring app for that (Maintenant), so LLM can inspect my stack easily.
> At Formal, we hate secrets. Since day one, we’ve been on a quest to drive the number of long-lived secrets in our infrastructure to zero.
Pedantry alert: Private keys are secrets.
I don’t find this pedantic at all, I just find the language used in the article to be genuinely confusing.
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
I mean I get the appeal, but that does mean that your agents also have the same level of access as you, and no way to limit actions to agents.
For us, most of our MCPs have non-undoable actions disabled. This is to stop agents writing a tool that recursively doing something silly.
As stated in the second paragraph of TFA, the machine workloads get their own infrastructure identity. Each identity can have different policies and permissions.
Yes, exactly, a cloud agent always authenticates itself (via OIDC) as an agent (machine) identity, with the option for the identity of the human who launched it to ride along.
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).
https://docs.formal.ai/docs/guides/policies/introduction
[dead]
Very bad idea and is just asking for the agent to breached itself via a bad prompt.
Not sure what you mean. How would it "breached" itself? Where would a bad prompt come from?
[flagged]