Original: https://codingcat.dev/podcast/identity-access-management-for-agents-with-tobin-south
Welcome back to CodingCat.dev! If you’ve ever found yourself neck-deep in the rabbit hole of identity, access management, and server security—especially in the brave new world of AI agents—today’s post is for you. I sat down with Dr. Tobin South, a security and AI expert, for a lively and insightful conversation that covers everything from fine-grained authentication and natural language access control (NLAC) to the nuances of Model Context Protocol (MCP) servers.
Whether you’re building your own MCP server or just curious about how identity management is evolving in AI-driven environments, this post will break it all down in simple, practical terms. And of course, we’ll share tons of real-world lessons, tips, and code to keep you safe, sane, and ahead of the curve.
“If you’re building an MCP server, you definitely need to check this out.” — Dr. Tobin South
Introduction: The Identity Management Problem in AI Agents
Have you ever handed over your admin credentials to an AI agent and prayed it wouldn’t accidentally nuke your production server? No? Just me? Well, as AI transforms the way we interact with infrastructure, applications, and even our inboxes, old-school identity and access management (IAM) tools are getting stretched to the limit.
In today's post, we’ll dig into:
- What fine-grained authentication looks like when AI agents drive the bus.
- How emerging protocols like MCP are reshaping best practices.
- The new problems (and hilariously dangerous pitfalls) you’ll encounter when serving up APIs for chatbots and generative models.
- Practical, real-world steps for building a secure MCP server today.
By the end of this post, you’ll have actionable advice on securing your MCP servers, managing agentic identities, and setting sane, practical access control—whether you’re at a startup or shipping software at scale.
Meet Dr. Tobin South: AI, Security, and the Academic Hustle
Dr. Tobin South is no stranger to the overlapping worlds of AI research, security, and enterprise software. After a wild ride through MIT’s AI scene (and a ChatGPT moment that changed everything), Tobin plunged into the depths of security—eventually landing at WorkOS, where he leads AI agent security, building MCP and IAM tooling for the world’s biggest AI labs.
“I spent a bunch of years thinking deeply about what AI security means... and there are really unique security challenges for agents.”
Tobin also runs a research lab at Stanford in partnership with Consumer Reports, focusing on consumer protection for the AI age. Think: safe transactional marketplaces, contextualized AI, and interoperable memory management.
- Academic meets industry: Practical solutions, experimental research, and policy influence.
- Stanford Consumer AI Lab: Where new ideas get dogfooded—and sometimes break stuff in spectacular fashion.
AI Security—The Agentic Future and Why It’s So Complex
Back in the day, security meant writing boring permission lists and hoping users wouldn’t share passwords. Now, with autonomous agents, you need identity infrastructure where an AI can “roam the web,” interact, and actually DO things for you—not just scrape content.
Key problems to solve:
- Delegated Authority: How do you ensure an AI agent only acts with your explicit permission?
- Safety Guarantees: What does “safe” mean when an agent can kill processes and buy tickets on your behalf?
- Fine-Grained Authentication: We’re moving beyond “all or nothing”—think scopes, context, and real-time oversight.
Dr. South’s Stanford research group throws crazy ideas at the wall (“what if agents could actually perform actions for you online?”) and asks the hard questions about identity, permission, and safe delegation.
Stanford Lab & Consumer Protection in the AI Age
It’s not just about writing safe code. What does consumer safety look like when you might soon be buying your next pair of pants through ChatGPT or Gemini? Stanford’s research lab runs experiments, advises students, and crafts real policy (like sections of the UN International AI Safety Report) on privacy and security.
How does an academic research lab work?
- Start with wild ideas—take them seriously.
- Ask students the off-the-wall questions (“what if agents roam the web?”).
- Conduct experiments to figure out what problems we need to solve.
- Feed findings into industry, policy, and standards.
Why it matters: As AI marketplaces, automation, and contextual memory get more complex, consumer safety requires new thinking—not just repackaging old IAM best practices.
How Standards Get Built: The OpenID Foundation and Fast-Moving MCP
Ever wondered how standards like OAuth, OpenID Connect, or MCP actually get written? According to Tobin, it’s equal parts collaboration, industry panic, and “LEGOs, not blueprints.” When the OpenID Foundation got curious about AI agents, Tobin helped launch a community group to pull together feedback from vendors, AI experts, and security pros.
- Dynamic world: MCP didn’t exist before October of last year.
- Fastest white paper ever: Industry is moving in real time, sometimes with “strongly held opinions in multiple directions.”
- MCP (Model Context Protocol): Enables standardized tool calling and state management for AI agents.
OAuth 2.1, Dynamic Client Registration, and What’s Next for MCP
Most security pros get nervous when words like "dynamic" and "client registration" pop up together. In the world of AI agents, it means your authorization server might need to let any agent connect—often pseudonymously. That sounds fun until you realize an agent could spawn a million applications in a single afternoon.
Recent changes:
- Client ID metadata—allows trusted agents (like Claude, ChatGPT) to declare themselves via DNS roots, so you don’t have to trust a random string.
- Dynamic Client Registration (DCR)—good for flexibility, but a big headache for security (“the wild west”).
Here's how it looks:
You get back a client_id and client_secret—but what’s to stop an agent from creating millions of these?
For background on DCR, read OAuth’s Dynamic Client Registration documentation.
The Security Challenges of Dynamic Tools and Agents
Imagine running VS Code and seeing a fresh OAuth client get created EVERY time you close and reopen your app. Or agents spawning millions of applications—each with their own keys and secrets. This is already happening in some test agents.
- Some agents create new applications each time
- Others reuse access tokens and clients
- Lack of standardization makes security unpredictable
Why standardization matters: As Tobin says,
“The wild west of technology is... very fun right up until the scale and the importance gets a bit too large.”
With AI, everything is happening at scale and speed we’ve never seen before. Even major players can’t keep up—hence the push for robust standards to ensure interoperability and safety.
Natural Language Access Control—NLAC, SORA, and the Evolution Beyond RBAC
Traditional access control models like RBAC (Role-Based Access Control), ABAC (Attribute-Based), and FGA (Fine-Grained Authorization) are starting to show their age—especially when AI agents interact via natural language. Enter NLAC—Natural Language Access Control—and new problems nobody saw coming.
Example: SORA App (AI Video Generation)
SORA lets you cameo friends in videos, turning on access so anyone can use your likeness. But the twist? You define what your AI deepfake can do using NATURAL LANGUAGE—just type it into a box.
“This is a crazy vision of the future of access controls on your own identity.”
Problems with NLAC:
- It’s not standardized.
- Scopes may need to be described in natural language.
- Enforcing control over NL is much harder than simple permission strings.
Agent-to-Agent Communication (A2A) — Natural Language, Power, and Worry
Say you want Salesforce AgentForce to talk to ServiceNow Agent—should they use a rigid API, or a more flexible natural language interface? Most agent-to-agent comms will happen over MCP, supporting arbitrary text-based requests.
Benefits:
- Unprecedented flexibility
- More powerful than strictly structured APIs
- Easier automation and integration
Drawback:
- Security is “terrifying”—hard to enforce precise control
- Restricting agents with scopes and permissions over NL remains challenging
Next-gen approaches may require sending and enforcing natural language scopes throughout the web. It gives users power, but opens new risks.
Fine-grained Permissions: NLAC, SSO, SKIM, and Context Management
We’re not likely to reinvent identity standards from scratch (“No, I don’t think we’re going to scan our eyeballs for World ID anytime soon”). Instead, Tobin argues we’ll adapt existing IAM protocols:
- OAuth 2.1, SSO, SKIM: Grabbing primitives from existing systems for provisioning and deprovisioning agents.
- Agentic Identity: “Halfway between a service account and a user.”
Problem: The complexity means OAuth standards (and MCP) will remain confusing and hard to use, but also robust.
The Real World: Setting Up an MCP Server the Right Way
Anyone can wrap an API behind an MCP server and throw an API key behind it. But that’s just scratching the surface—if you want safety, flexibility, and proper permissions, you need to go deeper.
Typical setup (v0):
- Wrap APIs behind MCP.
- Add API key or OAuth for access.
- Connect to Claude, ChatGPT, Gemini, etc.
- Roll with it.
But what’s wrong with this picture?
- Every user might supply an API key in unpredictable ways.
- Oauthing gives some identity, but how much access should you grant?
- Who controls which tools an agent can use, and when?
Here’s how Tobin suggests you level up your MCP server:
RBAC vs. Agent Trust
Don’t just map roles to permission sets. When an AI agent acts on behalf of an admin, it could have excessive privilege—like the Netlify CEO who accidentally took down the company’s core website!
Building Structured Tool Interfaces
Instead of exposing every API as its own tool, create general-purpose tools tailored to natural-language intents.
Designing Secure, Scalable API Access for AI Agents
Agents operate differently from humans. They can trigger API calls faster, in higher volume, and with less oversight. Standard dev-access patterns may be insufficient or dangerous.
- One API key per agent? Maybe for small use cases, but feels risky.
- OAuth tokens with scopes? Good, but how detailed and granular should scopes be?
- Dynamic tool access: Assigning access per user or per role.
“Your server text—the tool description—can completely change based on who connected to the server.”
Impersonation, Delegated Authority, and the On-Behalf-Of Problem
A common scenario: An executive assistant acts “on behalf of” the CEO, drafting or signing docs, but with more restrictions than the CEO herself. OAuth supports on-behalf-of flows and delegated authority, but actual adoption (especially in consumer use cases) is still spotty.
- Delegated Authority: Needed, but not widely supported.
- Consumer vs. Enterprise: Consumer platforms (Gemini, Claude, ChatGPT) own their agent ID; enterprises need robust audit, observability, and assurance.
Bottom-up adoption: As agents grow, repeated patterns will emerge, and organizations will need to balance flexibility, visibility, and compliance.
Agent Workflows, Orchestrations, and Real-World Security
Enter the orchestrators: Zapier, N8N, Google’s Agent SDK, OpenAI’s Agent SDK. Workflows let agents run asynchronously, acting on triggers and automating tasks across systems.
- Asynchronous agents: Have distinct identity and access challenges.
- Service accounts: In essence, but with dynamic, context-driven permissions.
- Human-in-the-loop still needed: Draft, review, and approve actions before sending.
This falls short of the holy grail—full workflow without constant approval—but strikes a balance between automation and oversight.
Fine-grained Access Control: FGA, NLAC, and Their Roles
Fine-Grained Access (FGA) lets you enforce dynamic, per-resource permissions—great for complex systems like Google Drive, less so for fast-moving, flexible AI tools. NLAC promises something even more adaptable, using natural language conditions and rules, but it’s hard to standardize.
- FGA: Powerful, but complex and heavy-weight for many agents.
- NLAC: Flexible, emerging, but not standardized.
Demo MCP Server Implementing FGA
Tobin built an MCP server where FGA is implemented INSIDE the server—tool descriptions and permissions are generated based on context, role, and conditions.
This approach is tricky, and NLAC might eventually overtake FGA in simplicity and flexibility.
What’s Next for MCP: Statelessness, Metadata, and Why the Future Is Fast
With the November 25th release of Model Context Protocol on the horizon, the most exciting development is statelessness in protocol design, making implementation and security easier for everyone.
“I’m very excited for a two-week rollout from a pure engineering perspective.”
Other improvements:
- Transport layer fixes
- Client ID metadata
- Better dev experience
- Responsibility in specs and standards
As AI agents go mainstream, and as protocols like MCP evolve at record speed, the standardization and incremental improvements will go a long way toward making this wild ride safe for everyone.
Curious to see all this in action, and hear more war stories from pioneers like Dr. Tobin South? Be sure to watch the full video on YouTube, subscribe to our channel, and join the conversation below.
What’s YOUR biggest challenge with access management for AI agents or MCP servers? Drop a comment, share your wins and “oops” moments, or let us know what you want to learn about next!
And don’t forget to follow us for more deep dives into the cutting edge of web dev, security, and AI!
External Must-Reads:
Stay curious, stay secure, and keep coding!
Top comments (0)