Managing identity in an era of autonomous AI starts with accepting an awkward fact: software that chooses how to complete a task cannot be governed like a user, a service account, or a predictable automation script. This webinar examines how to give autonomous agents distinct identities, constrain delegated authority, authenticate agent-to-agent calls, and preserve enough context to reconstruct what happened when an agent does something expensive, sensitive, or inexplicable.
.png)
.png)
Good morning, good afternoon, or evening, wherever you may be. We'll get things started here in about another minute or so — going to give people an opportunity to finish crawling in the door. So if you need to grab a drink or hit a quick bio break, now is your time.
Alright, we've given people a moment to wander in. Good morning. I am Brad McCarty. I lead product marketing for FusionAuth, and I am joined by somebody who has a whole lot more technical knowledge than I do, Dan Moore. Hi, Dan.
Hey, Brad. Looking forward to this conversation. I am the senior director of strategy and identity standards here at FusionAuth. Over the last six months or so, I've been digging into AI, so I'm super interested to talk to folks about this topic.
Dan, does that fit on a business card? That is one heck of a title.
You know? No.
To put it bluntly, no. Quick housekeeping notes: you will get a recording of this, sent to the email you used to register for the event. You're also going to get our white paper that accompanies this presentation — it was actually the data that went into what you're seeing today — and that will go to your email as well.
If you have questions, feel free to throw them in the Q&A box on the right, or just put a chat message in. You're welcome to throw a message in there at any time. Don't feel like you have to wait for the end. We will make some time for questions, but if something pops up, I would love to address it — or have Dan address it — in a timely manner.
So, welcome. Today we're going to be covering something that most security teams are probably already dealing with without even realizing it. AI agents are not a future threat. They are already operating in your infrastructure, most likely, whether you know it or not. The question is whether you have visibility and control over them. We're going to work through why more traditional identity models fail for autonomous software, look at some real-world failures, and give you a concrete road map to get started on this journey.
Let me start with some numbers to set the stage. The ratio of nonhuman identities to human identities has grown to 144 to 1 — that's a 56% increase in just the last year. At the same time, 23,800,000 new secrets were leaked on public GitHub repositories in 2024. And 70% of secrets leaked in 2022 are still active today, meaning there are still valid, exploitable credentials out there. This is not an abstract risk — this is the current state of everyone's attack surface.
As we go through this webinar, I'd encourage you to take a moment and think about whether you already have AI agents operating in your environment. Most likely, you do. The question then becomes: do you know about them, and do you have any control over them?
Hey, Brad — real quick. Can you go back to the previous slide? I just wanted to add a little nuance for anyone who's watching.
Just to be totally clear: not every nonhuman identity is an agent. Those are service accounts, pieces of software, scripts that are running. The point of that slide is not to say you have 144 agents running in your environment for every human. The point is that nonhuman identity is very widespread, and agents are going to work on top of that infrastructure — as we'll see further on in the slides. The fact is that we're unfortunately not taking very good care of our secrets or our security even for deterministic software, and agents add fuel to that fire. I just wanted to add a bit of nuance. Thanks.
For sure. And this slide actually gets into that a little bit — it's really defining what agents are within the confines of this webinar. We're not talking about a chatbot that responds to questions. An AI agent pursues goals autonomously. It decides how it needs to achieve those goals, takes actions sometimes in external systems, and then adapts when it encounters something it doesn't expect.
A travel concierge is a good example. You say, "Book me the same trip I booked to Cabo last year." The agent has to access your booking history, verify payment credentials, and complete a multistep checkout on a third-party site — all without you clicking confirm at every step. That's the fundamental security challenge: you've delegated both the goal and the method.
The key differences from traditional automation are in the table here. Behavior is adaptive, access patterns are unpredictable, scope spans systems instead of just one section, and agents make real decisions. That combination often ends up breaking security assumptions that have been hard-coded into application architecture.
Here's where most organizations run into trouble: they try to fit agents into existing identity categories, and none of them really work. You can't treat an agent like a user because agents, in most cases, can't do MFA, can't rotate passwords, and user-centric audit tools often capture the wrong context. You can't treat them like simple service accounts either, because service accounts have static permissions and no delegation model — they can't represent "this agent is acting on behalf of user X for task Y." It's also worth mentioning that service accounts can be and often are shared. And the most common failure is simply not addressing any of this at all — deploying with whatever credentials are convenient — which creates security and audit debt over time.
The underlying problem is that traditional security asks, "Did this agent have permission to take this action?" Agentic security also has to ask: Did this user actually authorize this method, not just this result? Was the delegation explicit? Was it auditable? And can a reasoning machine be manipulated into convincing itself that a restricted action is in fact justified? Suffice it to say, things get complex.
I want to make the argument for why AI agents are genuinely harder to govern than the service accounts and bots you're already managing. A service account runs the same database backup every night. You know exactly what it does, when it does it, what it touches. You can scope it precisely because the behavior is predictable. Agents are fundamentally different — they pursue a goal and then decide how to get there. That means their access patterns are dynamic, their scope can span multiple systems depending on what the task requires, and they make real decisions along the way. No other nonhuman identity does all four of those things simultaneously.
The practical consequence is that most organizations can't give you a complete list of the agents currently operating in their environment. Shadow AI is more prevalent than security teams expect. A developer builds an agent to automate a workflow. It works. It goes into production. Nobody ever filed a ticket with security. The question to ask your teams isn't whether you have AI agents — it's whether you know about all of them.
This slide addresses one of the learning promises from the overview directly: how do you untangle the black-box logic and create clear, compliant machine activity trails? The problem is painfully familiar to anyone who's done incident response on automated systems. You can see that the FinOps made a change, but you can't tell which agent did it, on whose behalf, or for what reason.
There are four root causes. First, no attribution — shared accounts make it impossible to isolate the actor. Second, no context — a log will capture the action but not necessarily the intent or the delegation chain. Third, no correlation — multi-agent workflows that span systems don't have linking IDs to stitch events together. And the compliance consequence is that regulations like SOX and GDPR require clear attribution of automated decisions. Fragmented identity makes evidence impossible to produce in a reasonable timeline.
The fix is intentional design. Every agent must capture six fields: which agent, which user, what action and resource, when and from where, and with what outcome — plus a correlation ID to link related steps. The technology to do this exists today. It's a design and process gap, not a tooling gap.
If you have questions or you're running into these problems yourself, please throw them in the chat or Q&A.
These three scenarios represent the most common real-world failure patterns. The first is the overprivileged agent. A customer service agent deployed with test-time database access was manipulated through prompt injection and exfiltrated thousands of records it was never meant to touch. Broad access granted at dev time never got scoped down before production, and a prompt injection attack turned convenience into a data breach.
The second is the untraceable action. Three agents sharing one service account left investigators unable to determine which agent made the suspicious financial transaction. The audit failed with no clear answer. A shared service account makes forensic investigation essentially impossible — you can see that something happened, but you can't say who did it.
The third is what I call the delegation disaster. An assistant agent scoped for calendar and travel held onto a token that also covered email. An attacker exploited the over-delegated authority to exfiltrate sensitive information. A developer had scoped the token broadly to avoid permission errors during testing. Nobody caught the over-scoping before it reached production. All three scenarios are preventable with the same underlying controls: individual agent identities, scoped tokens, and explicit delegation chains.
Now, these three are composites — things we've read about and studied without being specific about the companies. But this next one actually happened. This is the incident I want everyone to remember from this session. It perfectly illustrates every principle we've discussed.
It's not a sophisticated attack — no zero-days, no nation-state tooling. A bot account's personal access token was compromised. That's it. The bot had broad repository access. Attackers modified version tags retroactively so that any organization using that GitHub Action — and there were 23,000 of them — automatically pulled the malicious version. Secrets were dumped into public logs. CISA issued an emergency advisory. The entire blast radius came from one nonhuman identity with too much access and no accountability. If that bot account had been scoped to exactly what it needed and nothing more, the attack surface would have been a fraction of what it was. That's the argument for everything we've talked about so far today.
Now, I also promised a practical analysis of what happens when agents escalate their own privileges. In single-agent systems, this is mostly a configuration problem — the agent just has too much access. In multi-agent systems, it becomes an active attack vector.
Here's the pattern. A user delegates authority to an orchestrator agent, which delegates a subset of that authority to a specialist agent. If that specialist agent is then compromised — through a prompt injection attack, a supply chain compromise, or direct manipulation — it can attempt to elevate privileges by asking the orchestrator to perform an action on its behalf, exploiting the trust relationship between the two agents.
The key principle for preventing this is attenuation. At every point in the delegation chain, the downstream agent can have equal to or less than the upstream agent's authority — never more. This has to be enforced programmatically at each hop and never assumed. You also need mutual authentication between agents so that a malicious actor can't inject messages appearing to come from a legitimate agent. And you need the kind of chain-of-identity logging we discussed, so escalation attempts become visible.
Sorry, I just want to chime in on the previous slide. I need to wave my hands a bit earlier here. I want to reiterate mutual authentication — this is something that even a talk I was reading from OpenAI, where they described a multi-agent system with spans and correlation IDs, didn't address. And I realized that actually makes building agentic systems more complicated, because you have to have an authentication process — client credentials grant, API keys, short-lived API keys, certificates, whatever the solution is.
But when you do that, you also eliminate a huge class of issues. In the situation where a specialist is trying to call into the orchestrator because it's been prompted to do so, if the orchestrator is configured not to take any input except from the user, you block that entire class of bugs. Mutual authentication is just one bullet point here, but I want to say it's on par with attenuation in my mind. It's very important to have privileges decrease, but it's also very important to make sure calls are only going the way you want them to go. I realize this is a trade-off, the same way many trade-offs are between security and ease of implementation — but I wanted to call it out as something I'm not seeing a lot of people working on identity systems talk about yet, and it's going to become more and more important.
Yeah, that's a good point. And in pretty much every one of these situations, we have to look at where we are today versus where we think we might be in three months or six months. Things are moving so quickly, and we're all sort of building the airplane while we're flying it. There's a lot of work here that is a constant work in progress.
The good news is that tooling for implementing proper agent identity largely exists today. For service agents, the OAuth 2.0 client credentials flow is mature — a decade-old standard supported by FusionAuth and every other major identity provider. For delegated agents, RFC 8693 token exchange is the industry standard spec, though native support varies across providers.
For type three — collaborative agents — I want to be direct that "partially mature" is doing some real work in that label. This is the pattern where an orchestrator agent spins up specialist sub-agents, each of which may spin up further agents, all of them needing to carry and respect delegated authority from the original human user. The core security requirement is attenuation at every hop in the chain. The downstream agent must have equal to or less authority than the upstream agent that created it. No agent in the chain can grant permission that it doesn't itself possess.
The building blocks to enforce this exist today. You can use nested token exchange at each delegation hop, a policy engine like Open Policy Agent or Cedar to evaluate whether a requested action is within the calling agent's own authority, and correlation IDs to stitch the full chain together in the audit log. What doesn't exist yet is a standardized end-to-end protocol that governs all of this out of the box. Right now, every team building multi-agent systems is making their own architectural decisions about how to handle this — and that's exactly the kind of gap that tends to produce the privilege escalation scenarios we covered earlier.
Practical advice for anyone building or planning multi-agent workflows today: design the attenuation rules explicitly before you build. Don't assume the framework you're using enforces them for you. And make sure every agent-to-agent call is authenticated and logged with just enough context to reconstruct the full delegation chain after the fact.
Traditional RBAC was designed for a world where you know exactly what software will do. Agents break that assumption entirely. "Read customer data" as a role is far too coarse — it might mean one customer's record or all customers' records depending on what the agent is trying to accomplish. Permissions are static when agent tasks are dynamic. Context is ignored — 2 PM on a normal workflow looks identical to 2 AM from an unusual IP address if you're just checking roles. And there's no concept of delegation context in RBAC. You can't represent "this agent is acting on behalf of user X for task Y and should be constrained by both the agent's capability and the user's entitlement."
Modern agent authorization flips this. Instead of asking "does this identity have this role?", you can ask "does this specific agent have the right to make this specific request right now, in this context, on behalf of this user?" That's a fundamentally different question, and it requires policy-based dynamic authorization — which is exactly what fine-grained authorization systems like FusionAuth FGA by Permify are built for.
This is the practical starting point. I know the full scope of the problem can feel overwhelming, so I want to give you—
I just want to acknowledge this slide. Authorization models that are more complicated than RBAC take real work to implement. I've been working with some of the customers and users of FusionAuth FGA by Permify which is a ReBAC and ABAC solution. And one thing that comes up over and over is that there's an investment to be made. In an RBAC setup, you check a role in your application. With a ReBAC or ABAC solution — relationship-based access control or attribute-based access control — you need to gather that context and send it to the policy engine. That entails some additional complexity inside your application.
But what you gain is a fine-grained, guardrailed solution where the agent is more constrained than it would be with straight RBAC. The whole point is: we understand it's one thing to have it on a slide and say this is a good practice. It's another to say you need to commit. But we're making the argument that committing and building this into your application is going to pay dividends in the future by preventing the kinds of breaches and issues Brad talked about earlier. Just wanted to throw that out to add a little practitioner perspective.
Yeah, good context. And that's why I love having you on these webinars, Dan — you're a developer who has sat with customers face to face and spotted these problems firsthand.
So, back to the starting point. The full scope of this problem can feel really overwhelming, and that's kind of the point Dan was making. I want to give you a concrete sequence that's actually achievable.
Phase one is visibility. You can't secure agents you don't know about. Start with an honest inventory: What agents are deployed? What credentials do they use? What can those credentials access? Who owns every one of those agents? Most organizations are surprised by this exercise — shadow AI is more prevalent than security teams expect.
Phase two is hygiene. Fix the obvious problems your inventory reveals: credentials in source control, shared accounts, credentials that haven't rotated in a year or more. Now is your time to set things on the right path.
Phase three is the foundation. Implement proper authentication patterns so that new agents deploy with the right identity architecture by default.
Phase four is maturity: dynamic policy-based authorization, anomaly detection, human-in-the-loop controls for high-stakes operations. You don't need to finish phase four to be meaningfully safer. Getting through phase two alone eliminates the majority of the blast radius from credential compromise.
A few concrete rules to take back to your teams. Short-lived tokens — nonnegotiable. An hour is a reasonable default. A compromised token that expires in an hour causes far less damage than one that never expires. Every agent gets its own credentials, full stop — no shared accounts. Credentials live in secrets managers: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault — not in config files, application code, or environment files. Teams consistently underestimate how often those files get committed to version control, and even after removal they persist in your Git history. Automated rotation means no human has to remember to rotate a credential, and no credential goes stale for months or years. Monitor authentication events actively.
On the don't side: shared credentials are the single most damaging practice we see in the field. When all agents share a credential, a breach instantly affects every agent. You can't revoke one without breaking all of them, and you can never answer "which agent did this?" because they all share the same credentials.
Finally — and this one's important — don't conflate authentication with authorization. Authentication confirms who's asking. Authorization determines what that identity is actually permitted to do in this specific context. Agents require both independently. Passing authentication is not the same as having permission to take a given action.
The five principles are the framework I'd encourage you to use when evaluating your current posture and making the internal case for investment. Every agent needs its own identity — that's the foundational requirement, because without individual identity nothing else is possible. Authentication has to be robust: short-lived tokens, secret managers, automated rotation. Authorization must be dynamic: least privilege per task, not broad static roles. Delegation has to be explicit and attenuating — users must understand what they're authorizing, and authority must shrink as it goes down the chain; it can never grow. And everything has to be auditable, so that when something goes wrong you can reconstruct exactly what happened. Note that "attenuating" has been added to principle four based on our privilege escalation discussion — it's not an academic distinction, it's the specific control that prevents the agent chain attacks we described.
FusionAuth approaches this from a core belief — and we're not here to sell you anything, but I want you to understand the perspective and lens through which we're speaking. Human identity is the source of AI authority. Agents should inherit permissions from authenticated users and services. They should not invent their own authority. In practice, that means four things.
First, represent agents as first-class identities with their own scoped tokens tied to the initiating user's authority, so every action is attributable. Second, fine-grained authorization through our Permify integration — relationship-based, context-aware policies that can answer "can this agent take this specific action in this specific context?" rather than just checking a role. Third, audit logging that captures the full chain of identity: not just what happened, but who authorized it through which delegation chain. And fourth, authorization-aware RAG for AI knowledge systems. We authenticate the user, apply FGA to document access, and filter documents before they go into the vector retrieval pipeline. The LLM never sees content it's not permitted to access.
This last point is increasingly important as organizations build internal AI assistants on top of sensitive document repositories. There are some great tools out there that have already solved this problem. If you go to our website, you'll see the chatbot from Kapa AI. Kapa does a great job of building AI assistants you can actually control the way you should, instead of giving them free rein to access everything.
Here's a quick assessment. If you can't check every box in the inventory section, that's your starting point — you need to know what you have before you can secure it. If inventory is covered but authentication isn't, that's phase two work. If authentication is solid but authorization is still RBAC and not enforcing attenuation, that's phase three and four. I also want to flag the authorization section specifically: "attenuation is enforced at every delegation hop" is often not on anyone's checklist, and it should be.
The goal of this slide isn't to make you feel behind. It's to give you a clear, honest baseline so you can prioritize. Most organizations we've talked to can't check most of these boxes today, and that's okay — everything is moving faster than any of us would like. As long as you have a plan to close the gaps, you're going to be okay. You just have to have a plan and start to implement it.
To bring this all together: agents are already here. You don't have time to wait for a perfect solution before you start fixing things. Traditional identity models don't fit autonomous software. The gap creates real risk — audit failures, privilege escalation, compliance exposures, data breaches. The phased road map gives you a concrete starting point that doesn't require solving everything at once.
The framing I'd leave you with is this: the goal is not to prevent AI adoption. It's to make AI adoption sustainable — to build the identity infrastructure that lets your organization capture the value of autonomous software without the risks that come from deploying it without governance. That's a fundamentally achievable goal, with technology that already exists today.
That's it. That's what we have for you. I would love to hear your questions. Dan, I think you fielded a couple in the background there, so please go ahead.
Yeah. First of all, thanks, Brad — that was a great overview. And I love the fact that you were clear about this, because whenever I'm confronted with a bunch of checkboxes, I feel immediately inadequate. The honest truth is we're not here to make people feel that way. We're here to educate folks and share what we've learned and seen. Checking one box is better than checking no boxes.
And actually, one of the questions is: we all live in a world of finite resources, and how do you prioritize when the resources you have to take these steps are limited?
The question was: we all know we live in a world with limited resources, teams are strapped, new features need to be developed. How do you prioritize agentic security efforts when resources are limited?
That's an interesting question, and one we're kind of working through internally post the Permify acquisition. I think the first thing is to find out who it's going to benefit and how much they actually need or want it. All of this requires dev resources that are limited. But then beyond that — for someone on an engineering team with direct access — how do you make those decisions, Dan?
I think the first thing you want to do is think about inventory. This is common cybersecurity best practice — the first thing you do is find out where all the things are, and that's just as true with agents as it is in other situations. And it actually helps you understand the scope of the problem. It's not just a relatively easy first step — it's something that helps you figure out what you're dealing with. If you have a million agents, you have a different kind of problem than if you have a thousand or ten. That's where I would start.
Yeah. And then further to that, once you've spotted these problems, how do you make the business case to leadership? How do you convince them that this is worth the time, effort, and resources?
I think there are kind of two aspects. First — and this may sound cynical, but it's real — anything that has the word "AI" on it gets people's attention in executive leadership right now. So there's that angle: here's the shiny new thing. But then you can lean back into the specific details around the risk of nonhuman identities. The tj-actions incident affected tens of thousands of GitHub repos. And Asana had an incident where their MCP server was incorrectly scoped and allowed cross-tenant access. Even when you're sprinkling AI on things, some of these foundational security principles are just the same. Compliance and security are good ways to approach this conversation — and you'll get even more attention because you can connect it to AI. Do you have thoughts on that, Brad?
I think that's exactly it. There are so many stories of teams just starting to figure this out and making the business case. When you go out and start using board-level language — "there were 23,000 organizations affected and it required a CISA advisory" — that kind of framing is going to get people's attention regardless of where you are in your process.
Yep. That's great. I think that's all the questions. If anyone has one more, we'll give you five seconds to type it in. But if not, really appreciate all the knowledge you dropped, Brad — it was great. Can you remind everyone: will people be able to watch the recording again?
Yeah. You will absolutely get a link to the recording of this webinar, and you'll have the deck available to you as well. The white paper for securing autonomous AI agents is going to come to the email you registered with. So you should be getting a plethora of material from us in probably the next twenty-four hours or so.
Great.
Well, Dan, thank you so much. I really appreciate your technical knowledge on this and for keeping me honest. Keep an eye on the FusionAuth website — it's fusionauth.io/webinar — because we've got some more great stuff coming your way in the not too distant future. Thanks again.
Thanks, everyone.
