My workday is scattered across many disconnected tools: Google Calendar, Linear, Gmail, Google Docs, GitHub, Slack, and Granola meeting notes. No s...
For further actions, you may consider blocking this person and/or reporting abuse
the security piece is the part most people skip entirely when building agents. I spent way too long on a planning tool before realizing I had basically zero boundaries on what it could access - just trusted the model to be sensible. using something like Keycard to actually enforce those boundaries at the auth layer makes a lot more sense than hoping the system prompt holds. gonna look into MCP more seriously now
Great job in handling Least Privilege, Long-Lived Secret and Black Box issues
Love the practical approach. Theory is nice, but hands-on examples are better.
As a beginner, I am gonna read this I think for a week and study it, thanks for sharing nice post!
You're welcome, thanks so much for reading! Please let me know if you have any questions at all!
This is a really thoughtful treatment of OAuth delegation and least-privilege—especially compared to the usual "just give the agent a long-lived token" pattern.
One thing I want to flag for readers planning to move this toward production: this architecture meaningfully improves identity and token handling, but it does not make the overall agent system "secure" in the broader sense.
In particular, the stack here still has:
— An unconstrained LLM reasoning loop (planning, re-planning, tool selection)
— No deterministic guardrails on multi-step tool-call sequences
— An agent that can read/write its own local state store
— No substrate-level containment or formal policy enforcement on agent behavior
That's not a criticism of this post—it's doing a great job at the OAuth/delegation layer. I just want beginners and implementers to be careful not to equate:
"Secure token issuance and least-privilege access" ≡ "Secure agent infrastructure suitable for production autonomy."
If you treat this as a secure way to delegate OAuth access to an otherwise non-contained agent, it's a strong pattern. If you treat it as a generally secure agent architecture for production deployment, you're going to miss the reasoning loop itself as an attack surface—and that's where the real exposure lives.
Great callout and distinction. It's not end-to-end security, by any means. You'd certainly want to use something like Promptfoo for that. I didn't in this case because it's a personal, local tool I'm not exposing to the public internet. I'm the only person who uses it. There's an entire host of production deployment security horrors awaiting anyone who assumes not addressing the things you mentioned is okay to do in a deployed production multi-tenant version of this. I hope I was clear about the intent of this project and its scope, but it probably does bear repeating.
Awesome post. Really enjoyed this one! Been struggling with auth/access to tools. Super helpful to read through your perspective here
Thank you, really glad it was helpful! There are so many ways agents can help or harm when it comes to tool access... fully autonomous agents that operate on behalf of themselves or unauthenticated users, automations, or workflows, delegated access with human-in-the-loop, and everything in between. This was a delegation project, but I'm also working on securing a fully autonomous agent with no human access delegation (anonymous human users of unknown intent!). The team internally also just dropped new policy features, so I'm busily testing those out too. Please let me know if there are specific problems you've run into with auth / agent access, I'd love to know what challenges other people are trying to overcome! And thanks very much for reading. :)
keycard's solid. only wondering how the agent handles cascading auth failures — like if it chains 5 tools and #3 blocks, does the whole plan fail or does it have fallback logic? we hit that exact nightmare in production and ended up having to rebuild the whole orchestration layer.
Keycard returns a rich information set on denial, which enables the agent to interpret the failure. We're also going to introduce remediation (near-term roadmap) which will provide additional context on how the agent may resolve the authorization failure. This could:
Good 👍