Per-conversation permissions that grow as needed feel like the right direction, but they move the hard part to the approval step. If the agent asks for more access mid-task, the request itself can be shaped by whatever it just read, so a poisoned issue or doc can make it ask for exactly the scope an attacker wants. And people approving prompts all day will click yes, the same way they did with OAuth consent screens. I'd tie every grant to the person who started the conversation and cap it at what that person could do themselves, so the agent never holds more authority than its principal. How do you see cron and webhook agents fitting in, where there is nobody in the loop to ask?
The conversation-level grant still has to be a different credential from the team agent that owns the box. A chat that is supposed to be Salesforce-only can run inside the engineering agent that already has a git token, and asking for more scopes mid-conversation adds the new grant to that same process. I'd mint a token for this conversation that cannot see the team agent's other secrets, and drop it when the chat ends, rather than widening the long-lived identity. Otherwise "scopes for this conversation" is a label on an agent that still has yesterday's access.
Per-conversation permissions that grow as needed feel like the right direction, but they move the hard part to the approval step. If the agent asks for more access mid-task, the request itself can be shaped by whatever it just read, so a poisoned issue or doc can make it ask for exactly the scope an attacker wants. And people approving prompts all day will click yes, the same way they did with OAuth consent screens. I'd tie every grant to the person who started the conversation and cap it at what that person could do themselves, so the agent never holds more authority than its principal. How do you see cron and webhook agents fitting in, where there is nobody in the loop to ask?
The conversation-level grant still has to be a different credential from the team agent that owns the box. A chat that is supposed to be Salesforce-only can run inside the engineering agent that already has a git token, and asking for more scopes mid-conversation adds the new grant to that same process. I'd mint a token for this conversation that cannot see the team agent's other secrets, and drop it when the chat ends, rather than widening the long-lived identity. Otherwise "scopes for this conversation" is a label on an agent that still has yesterday's access.
so does this become a JIT generated iam?
That's what I think, but figuring out how to make that ergonomic and avoid approval fatigue is its own problem
I’m an IAM consultant, so I’m interested. How does your stuff compare with Sailpoint’s?
No idea, I haven't used sailpoint. Happy to jump on a call though and talk through things