Securing AI agents exposes a gap your CIAM stack was never built to fill: agents aren't users. They don't have passwords, they don't get frustrated by MFA prompts, they can spin up a hundred instances in ten minutes, and when they go rogue, they do it at machine speed. FusionAuth's Dan Moore walks through the identity architecture that closes that gap. You'll leave with a concrete model for tracing authority from human principal to sub-agent, a clear understanding of why OAuth scopes aren't enough for agentic authorization, and two specific patterns (the token vault and sub-agent mutual authentication) for limiting the damage when something goes wrong.
.png)
.png)
Hello everyone, and welcome to today's DZone webinar, "Securing AI Agents with MCP and Zero Trust Identity." I'm Max Crampton-Thomas and I'll be your host for today's session.
As AI-powered systems become more autonomous, a new kind of user is emerging inside modern applications: AI agents. These non-human actors interact with APIs, tools, and enterprise data at machine speed, which introduces entirely new identity and authorization challenges. Traditional CIAM systems were built for humans — users with passwords, sessions, and login flows. AI agents operate very differently, and securing them requires a new approach. In today's session, we'll explore how identity strategies are evolving to support this shift, and how teams can apply zero trust principles to AI-driven systems.
Before we get started, a bit of quick housekeeping. Today's session is being recorded and we'll send the on-demand recording after the event. If you have questions during the presentation, please submit them using the Q&A panel and we'll address as many as we can during the Q&A portion at the end.
Now, I am pleased to introduce our speaker. Dan Moore is the Senior Director for CIAM Strategy and Identity Standards at FusionAuth, where he helps organizations design secure identity solutions, contributes to identity standards, and educates developers about authentication and OAuth. A former CTO, technical trainer, engineering manager, and longtime developer, Dan has been building software for more than 25 years. Dan, thanks for joining us today, and I'll go ahead and hand it over to you.
Thank you so much. Really appreciate it, and thanks for that intro. I'm super excited to talk to you about this topic today. Real quick, I work for a company called FusionAuth. We're a customer identity and access management system, so we understand how users authenticate and how to have them take that important operation securely. AI agents are a new and exciting area for identity and for authentication.
I think that a couple years ago, LLMs were very, very exciting. There has been an evolution over time. We started out with RAG, where we're basically making documents available to LLMs — not really putting them in there, but putting them in vector databases in order to augment the LLM after training. Then last year felt like the year of MCP, where everybody was rolling out an MCP server. It was very exciting. There were a couple of different releases of the MCP specification and it really grew up. The idea of AI or LLMs taking actions in the real world through APIs or MCP really increased the usefulness of these systems. And now we're with agents, where these systems can be — I don't want to say entirely self-directed — but you can give them high-level tasks and they can break things down into steps and meaningfully change the world or take action based on direction from human beings or other systems.
As this evolution has happened, there's an increasing risk. Just like when a child is very small, the damage they can do is limited. When all you're doing is having an LLM read documents or use tools in a limited fashion, the damage is limited. Whereas an adult can drive a car or take other action that is way more useful, but it can also be abused. And so the more power these agents have, the more you need to constrain that power or direct it in the right way.
I do think that a lot of folks here probably are familiar with agents, and we'll be asking you some questions. This isn't going to just be me talking at you for 25 or 30 minutes. I'd love if you use the Q&A tab, but we'll also have some polls coming up — we'll be asking about your experience with agents as well.
An agent is semi-autonomous. The reason why I say semi-autonomous is because most agents I've seen or am familiar with are not acting totally on their own devices. They are taking a request from a human being, or they are started up by a human being or a team of human beings to achieve some task. So they're semi-autonomous, and they are self-directed. When it comes to the what and the why, that's a human's task. When it comes to the how, that's the agent. And that's really where the evolution has unlocked new capabilities. They can break tasks down and they can choose how to accomplish them in different ways. But to do so, it is going to access data and APIs. AI agent is kind of a fluffy concept, but these are three attributes that we see of AI agents.
I will say that probably a lot of you are familiar with Claude Code or Codex or other coding agents. The nice thing about a coding agent is that it's constrained in very real ways. How is it constrained? For one, it's operating on a file system. Two, it has tests that can tell you whether or not the changes it has made have the desired effect. Tests aren't perfect, but they are deterministic. They can be written by agents, and they are something that you can use to set guardrails around any changes that other agents or other systems make to a codebase. And the third big constraint is that the changes get pushed up to a central repository — a GitHub or a GitLab or what have you. That's a clean break.
Coding agents are not what we're going to talk about today. But the whole point of securing AI agents is that you want to set similar constraints around any agents that are out there in the network doing business processes or otherwise operating on your data and your systems. So we're not going to talk about coding agents, but what we're looking to do is have this concept of constraints and guardrails around agents that are similar to what we have delivered with coding agents.
A couple of principles — and this is something I'm going to repeat and reference back to throughout this talk. First, you don't want to reinvent the wheel. I was actually just talking to a friend today about this, and it feels like I'm hearing so many echoes of some of the API discussions and architectures that we went through and discovered at great cost in the 2010s. So whether it's standards like OAuth or architectural components like orchestration layers or gateways or service discovery — just because AI enables new capabilities, don't forget that there are long-lived, well-tested, well-understood patterns around securing access to AI and APIs. Don't forget to reuse those. Don't feel like you have to reinvent everything from scratch.
The second key principle is that human identity is a source of authority. This gets back to the semi-autonomous nature of agents that I talked about before. Basically, a human being requested it. A human being set up the workflow. A human being configured this agent to go do something. That is the root of authority. So you want to make sure you keep track of that as the agent is doing things or creating new sub-agents. You want to make sure that you can trace things back to human beings, because they are going to be the ultimate source of the credentials and permissions that the agent has to do things.
The final principle is that you want to give every agent an identity. This is something that you wouldn't necessarily do for every subroutine or every CLI or every piece of deterministic code. But because agents are non-deterministic, and because you need to set those constraints around them, you need some way to log and audit and make sure those constraints are followed, or to debug things and get back to the root source if there are issues. That all implies that agents have distinct identity. We'll talk a little bit more about that in the coming slides.
Real quick poll here. I'd like to know what you all are using agents for. Let me see whether I can bring up this poll. I think this is really fascinating. A chunk of you are using it for business processes. Content pipelines. Coding is by far the most common use of agents. Some brave folks among you are using OpenClaw or having AI be a chief of staff, which is fantastic. And then some of you are here for other reasons or just to learn, which is great.
That kind of jibes with my experience. You talk about AI with people at a conference or in your daily life if you're a nerd like me, and you hear a lot of "really useful for coding, experimenting with other uses." Because of some of the constraints, or the nascent nature of securing AI agents, I think that coding right now is one of the primary use cases.
Let's talk about something that Max mentioned in the intro — some of the differences between CIAM, which again is where FusionAuth cut its teeth and has a really good understanding of the problem space, versus non-human identity. You can see that the way that the entity, whether it's a human or an agent, is authenticated is different. The interaction speed is different as well. Humans think on the order of seconds to minutes to hours, whereas agents, being software, can operate at much higher speeds. They also are capable of running into walls much faster and much more repeatedly than human beings are.
Human beings, because of that slow nature and because we have agency, tend to have long-lived sessions. I don't know about you all, but I hate to log into Google when I get that prompt that says, "It's been a couple of weeks. It's time for you to log in again." That is frustrating to me. Whereas agents have sessions that differ in two major dimensions. The first is that they're going to be ephemeral. The reason for that is that, unlike a human being, I can start up an agent, ask it to do one small task, and then shut it down again. And I can do that as many times as I want. Whereas if I did that to my coworker, they would be kind of peeved. They'd be frustrated. So agent sessions are going to be ephemeral, and they also can scale up in ways that human beings can't. If I am facing a problem that I need a hundred agents for, for 10 minutes, I may need to create a bunch of identities and have a way to deal with those identities at scale, assign the right permissions, and do other things that I wouldn't do because I'm not going to bring 100 people into a room for 10 minutes repeatedly. If you're doing that regularly for your business processes, that might be an indication that something's wrong.
The last major difference between humans and non-human identities is orchestration. With a human being, we are all self-directed. You may be taking direction from a manager or from a spouse — I take plenty of directions from my kids, I'll be totally honest with you — but in most of the actions in my life, I'm self-directed. Whereas agents are taking those prompts from external systems, whether that's a human being directly or an orchestration layer that is examining those prompts and doing some security checks on them or otherwise coordinating. So those are some of the major differences between these two types of entities.
Real quick, talking about capabilities. These are three major areas where we've seen LLMs or AI-based systems need to have identity mixed in. With RAG — retrieval augmented generation, which I alluded to on the second slide — the real issue there with identity is you want to make sure that the provenance of a document that you are putting into a vector database is tracked, so that the correct documents or chunks can be returned, or more importantly, so the correct documents or chunks can be omitted. If Dan has a position at a company that is HR, and is interacting with a RAG system that's been built for that company, he's going to see different documents than Max would. If Max were an engineering manager, we would need different levels of access, and you need to make sure that that gets passed through in a RAG system.
With tool use, it's much more about the credentials. That could be API keys, it could be OAuth access tokens. We'll talk more about the different kinds of tool use, but it really is about the agent or the LLM holding the credential and then presenting it to the services that it needs to access to get the answers, or to get the tasks that it has been asked to do done. And then with agents, we just talked a little bit about the different ways that identity can fit in there.
Digging into that last bullet point a little more, and echoing one of the key principles: you want to give agents first-class identity. You want to avoid shared service accounts — that makes auditing and logging and debugging much more difficult. And then you want to make sure that you are prepared for those two dimensions of agentic identity: the ephemerality of starting them up and stopping them rapidly, and also the ability to scale up.
One important concept that I want to introduce here is called the chain of identity, and this is related to the provenance of the RAG documents that we talked about earlier. If you have a human being that makes a request of an agent, and then that agent makes requests of other agents down the line, you want to make sure that you're tracking all of those identities. That's going to help with auditing, it's going to help with debugging, and it's going to help with security, because you can know who made the request and what agents it went through. And conceivably you can lock down their credentials as it's passing through the system.
The act claim, which is mentioned here, is part of the RFC 8693 standard. There's a corresponding sub claim. Basically, the act claim is "I'm acting on behalf of," and the sub claim is the thing that is being acted on behalf of. So if I create an agent that's doing things on my behalf, that agent's ID is going to be in the act claim of a JSON Web Token, and my identity will be in the sub claim. By wrapping it up in a JSON Web Token, you get benefits: it can be signed, it can be verified that it was issued by a certain identity provider or a certain holder or private key, and you can pass it along the entire chain. It can be embedded in requests. It can be put into logging systems.
I mentioned RFC 8693 — that is the standardized way to do this. If you are using an IdP that doesn't support RFC 8693, which is the token exchange grant, you can use native APIs if necessary. But I would recommend either way that you use the JSON Web Token structure in 8693 for compatibility, and also because I'm a big fan of following standards. A lot of smart people have put a lot of effort into that standard.
When I mention having like a four- or five-deep chain of identity, which is possible if your agents are spawning other agents, then you might say, "Well Dan, how long does that chain need to be, and how big does that JSON Web Token get?" The answer really depends on what you're using it for. If you're using it for authorization and the chain is important for authorization decisions, then sorry, you've got to put it all in there. If you're just using it for auditing, then you can probably get by with the original human that is kicking off the request — or if it's a cron job, the identity of that cron job — and then the agent that is taking the action, and maybe the agent that called it, the parent agent. You can get by with those three things being in the JSON Web Token.
Let's talk a little bit about tooling. This is really important because, as I mentioned, last year was the year of MCP, and it feels like that is the year that agents really started to interact with the real world in a standardized fashion. But the more I dig into this, the more I am realizing that MCP got a lot of the attention last year, but it's not the only way. And in some ways, it's not the best way to interact with the real world.
You have just plain old APIs. I can't tell you how many times Claude has just basically built a fetch call instead of using an MCP server for me. You have SDKs as well, which can be layered on top of APIs but can also incorporate other business logic. SDKs are nice because they can take care of things like rate limiting or retries. And then you have CLIs, and CLIs feel like a — how do I put this? — kind of a "what is old is new again" situation, where CLIs are useful for agents that have access to the file system, because they are compact, because they're discoverable, and because they can be deployed fairly easily.
So the point of the slide is: don't just focus on securing your agentic access to MCP servers. You also want to think about credentials for APIs and SDKs as well.
MCP, in my mind, is just another form of an API. That said, if you're looking to just educate your agent about your service or your API, I would just use a skill. That's something that's happened in the last six months or so. But if you have centralized data and functionality that you have business rules around, then MCP is great for that.
MCP, when it's living in the network world, is typically integrated with an authorization server. The way this works is: the client tries to use the MCP server. The MCP server says, "Hey, no way, José. I'm going to redirect you to an authorization server because I don't know who you are." The authorization server authenticates the user and mints an access token, which is then sent to the client, and then the client holds that and presents it to the MCP server, and access is granted.
You may say, "Dan, what about agents that don't have easy access to a human being to go through this process?" The answer is twofold. Either you use a token vault, where a human being has previously authenticated and there's a deterministic system that stores the refresh token, which can then be used to get an access token. Or you use the client credentials grant, or something else where the agent itself has the authority.
The problem with tools — and this is true, I think, for most OAuth-based tools — is that scopes are not enough. They don't give you enough granularity for authorization decisions. With Google, which is very sophisticated in terms of the authorization infrastructure they make available via OAuth, you cannot say, "I want this agent to access my Google Drive, but only this folder. I want it to only be able to read files in this folder, and I want it only to be able to do that for the next hour." That is just not something you can represent with OAuth scopes. You can use a standard called Rich Authorization Requests to represent that, but guess what? If your API behind the scenes that receives that access token doesn't support that granular access, you're out of luck.
This is something I feel passionate about. I think it's great that MCP supports OAuth, and scopes are a definite big step in advancing the authorization story. But whether it's delegated tokens or client credentials grant, if you don't have the fine-grained authorization behind your APIs, you're going to run into trouble. There are services out there where you can externalize your authorization. Permify is one that FusionAuth just acquired. It's open source. You can go kick the tires on it, but you can also build it into your application. Don't sleep on the fine-grained authorization you need to protect agents acting against your APIs.
Real quick poll: what tools do your AIs use? I'm curious, of those ones that we talked about — APIs or SDKs or CLIs — which ones are you all using? Let's just see. A lot of folks using MCP, a lot of folks using APIs and SDKs. Interesting that CLIs are also there. So I see a wide range, which is always interesting to me. I think that just goes to show that not every AI system needs to use the latest and greatest. SDKs — especially if your agents have a lot of knowledge around how to use them, because you've either made the docs available via RAG or trained on the docs — are a great way to interact with these systems.
All right, I am talking a little bit faster because I want to get through all my slides and definitely have time for our questions. We're going to wind it down with a discussion of the bigger picture. This is what we think of as the security stack for agentic systems. In the resources section, there's actually a PDF you can download that digs into each of these 10 ways of securing agentic systems in a lot more detail. I'm not going to talk about them all, but I want to talk about the categories, and then we're going to dig into three.
The first category is foundational, and these are just table stakes. You have to have these in your agentic systems in order to run them securely. Important defenses are built on top of the foundational ones and are very common in agentic systems, but you're not necessarily going to see all of the important defenses in every system. And then force multipliers are, for a variety of reasons, useful but not necessarily critical. They could be useful because they're easy to implement, or because they cover a narrow problem very well, or because they help you build more maintainable systems over time. But they're not as important as the other two categories. So we're going to talk about two of the foundational ones, and then we're going to talk about one of the important ones.
One of these foundational ones is that you want to limit your service access. This is the same reason that you don't want to give your developers admin access to your production AWS account or cloud account. You want to limit the scope of damage that any non-deterministic system can do — frankly, any deterministic system as well. You can do this with AI agents by limiting their tool access to tools that they need to do their job, and with whatever credentials they need to access those tools, you want to have those be downscoped as much as possible.
A pattern we've seen that does this is, as I alluded to earlier, called the token vault, where you don't let the agents get their credentials for interacting with a third-party service like Google or Box for documents at all. You actually have that delivered by the orchestration layer. The orchestration layer retrieves a long-lived refresh token from a vault where it has previously been placed, either via human authentication or some other process. Then it takes that refresh token, presents it to the API, gets back an access token — hopefully it can downscope it, that does depend on the API — and then that token is what's presented to the AI agent to do what it needs to do.
This does a great job of making sure that if an agent is compromised via prompt injection or some other mechanism, it is not going to be able to exfiltrate credentials that are dangerous. It might be able to exfiltrate the credential, but if it expires in 10 seconds or 60 seconds, well, that's less of a risk than if it's a long-lived refresh token that can be used to mint new access tokens.
Another really critical piece for securing AI agents is logging and tracing. Again, no surprise here. If you're in the cybersecurity world, you know that logging and tracing and anomaly detection are really, really important things. You want to, as I mentioned earlier, maintain that chain of identity for your auditing and for your security processes. One important point here, again echoing back to that key principle of "don't reinvent the wheel": leverage your existing security infrastructure. Put these logs into your SIEM system. And you have a side benefit by doing good logging and tracing, which probably happens at the orchestration layer. When an agent makes a decision, when an agent reaches out and accesses a tool, you can log all that, and that will help with debugging any issues with your agentic workflows and also with any performance issues you run into.
Sub-agents are the final part of the security stack I'm going to dig into, and this is where zero trust comes in. You basically want your agents to mutually authenticate, and you want to do this in as automated a fashion as you can. The idea here — and I have this on the next slide — is that if I have an agent that spins off multiple sub-agents to do various things (reach out to Google Drive and read some documents, talk to an API, schedule something on a calendar), if I have these agents mutually authenticate via mTLS or client credentials grant or even shared API keys, then I can make sure that the orchestrator agent is the only one that is talking to each of the sub-agents, and they can't talk to each other.
So if the document agent hallucinates, or gets malformed instructions that are buggy, or receives a prompt that is malicious, or does something else that's dangerous — well, it can definitely affect Google Drive based on the permissions it has to do that, but it can't affect the calendar. It can't affect that other API. For the same reason that we create subroutines and submodules and microservices and separate out services, we're going to do the same thing with agents. The nice thing is that we can have them mutually authenticate so that we don't need those boundaries necessarily to be physical. They can be logical. They can be with authentication.
I think I had one more point about the sub-agents. Basically, you limit the blast radius if things go wrong, and you should leverage standards like I mentioned earlier to do so.
So to reiterate, we're coming up on the end of our time. Principles: please don't reinvent the wheel. Go look and think about all the lessons you learned during the API explosion of the 2010s, or go read about them if you weren't around then. Look at the standards — there's a lot of great work happening in this space. And don't just think about the standards, but also think about the architectural components. Human identity is the source of authority, so make sure you maintain that chain of identity, and make sure that you give every agent identity for that purpose. I think that is all the time I have for talking, but I would love to hear any questions that you all have.
Well, thanks Dan. That was a really insightful look at how identity and authorization models are evolving as AI agents become more deeply integrated into modern systems. I do want to move into the Q&A portion of this session. As a reminder, you can submit your questions using the Q&A panel. We do have a little bit of time here, so Dan, let's go ahead and jump into a couple of questions from our audience.
The first one I see here is: is that a similar concept to the assumption of role slash identity? I think they're referring to the chain of identity.
I think it's slightly different than assumption, because you can think about the difference between impersonation and delegation. This actually is covered in the 8693 spec. Impersonation is: I am acting as Max, and I can do all the things I can do as Max. Sudo is another example of impersonation. Whereas the chain of identity is really about capturing that delegation chain. And again, I mentioned downscoping in the token vault example, but you can also imagine the credentials that are being passed around being downscoped between different agents as well. So it's slightly different than assuming a role. But great question, thank you.
Yeah, absolutely. The next question here: what does the phrase "human identity is the source of AI authority" mean?
Just like we would never give a cron job its own authority — it always is vested in the team that set it up, it's acting on behalf of a human being — an agent should never have its own inherent rights. The power that it uses to access tools, to access other systems, should always be able to be traced back to a human principal or set of human principals, a team that authorized it. I mentioned it twice in my slides because I think it's really important. Agents are really acting on behalf of us, and we want to make sure we can trace that back to have proper security and provenance and governance.
No, absolutely. I think it's important to reiterate. We've had quite a few questions come through here, so I'm just kind of running through them now. What is the purpose of the act (actor) claim in a JWT for AI agents?
Great question. So this again is coming out of RFC 8693. It lets you build a nested chain of identity that shows that the agent in question is the actor. There's going to be an ID associated with that agent, and then you can actually nest it. I should really have put this into the slides. If agent A delegates to agent B, then agent B is acting on behalf of agent A. If agent B then delegates to agent C to do something else, then agent C is acting on behalf of agent B, which is acting on behalf of agent A. And so the act claim — I believe it's the act claim — gets this nested set of claims, where you can very easily put that into a log or examine that in a programmatic manner to determine where did this request come from and who made that request.
We had another question come through here. Is there any governance framework that you can recommend, with some open-source available ones, language agnostic, to manage multi-agent identity coordination?
This is definitely an emerging area, and I don't have any great recommendations. I know the OpenID Foundation has published a white paper about this, and as indicated by my title, I kind of have a bent toward identity standards, so I probably would look to that. But I don't think it's been turned into code. A lot of the agentic frameworks I've been looking at, again, focus more on the coding agents and the file system level of governance. They don't take a look at the bigger picture. So I'm sorry, I don't have a recommendation about that.
That is still a good answer. Why is MCP not a complete security layer?
MCP handles transport and communication between the model and the data, and then it has a section about authentication — or authorization — but that is layered on top of OAuth scopes. I hope that I was passionate enough about OAuth scopes to convince you that they're very coarse-grained. They're a great start, but for most agentic requests you're definitely going to want something that authorizes at a finer level than OAuth scopes.
Then, what is the security benefit of using sub-agents instead of one single agent?
Again, it's the same as the reason why you use microservices, or even services in a monolithic application. You don't want everything responsible for everything all at once, because you could end up with bugs that cause issues. You could end up with malicious actors that could cause issues. You basically limit the blast radius when you're using sub-agents.
I don't know if any of you have read Simon Willison's "lethal trifecta" blog post, but it's a really important one to read. Basically it says that if an agent can read private data, can take outside prompts, and can write to external systems, then you can exfiltrate data, and it's very, very hard to protect against. Well, one way to protect against it is to not have one agent that does all those things — to have three agents. Again, that doesn't — the same way that adding a firewall to a server doesn't protect against everything, but it just makes things that much harder and can cause attackers to go away, because they're looking for the open windows to walk into, to mix my metaphors. Sub-agents add that extra layer of protection and limit the blast radius if something goes awry.
And it looks like we've got one more question here. Is there an analog to step-up authentication for an agent?
Yeah, and this is something that I did not get to because I wanted to respect you all's time, but I'm kind of shifting back to this defense in depth. There's human interaction, which is kind of an analog to step-up authentication. I don't know if any of you all have logged in from a different device to your bank or something like that, and then you get that "hey, please enter this code," or "we texted you something" — that is step-up authentication. Agentic systems have a similar thing, where there can be a human in the loop. We see this with Claude Code or coding systems, which I know a lot of you are familiar with from the poll, where it says, "Hey, I'm about to do this thing. I'm about to read this file," or "I want to go look in this other directory. Can I do this?" That is an example of human interaction, which is an analog to step-up authentication.
What you want to be careful of — and I wish we had time for another poll, because I would like to ask, of the people who are using coding agents, how many of them carefully and methodically examine everything that Claude Code or Codex or whatever agent you're using asks you to do? I don't. I probably examined the first five, and then I was like, "screw this, yes, yes, yes." Or I was like "no," because I don't ever want to be asked about this again.
So the analog is very real: if your bank asked you to MFA, to step up, every time you logged in or every time you looked at your account portal, you would quickly fatigue of that and you would just choose one of those two paths — always yes or always no, which are both dangerous paths. With human interaction in agentic systems, you want to do the same thing. You want to be very careful about how often you ask for that. You want to think about, am I going to ask just for things that are over a certain dollar amount or have a certain amount of damaging action? Or do I want to ask about things the first five times and then just kind of assume a yes, because the users hit yes a number of times, and then I'll just ask every 10th time? So you want to be very cautious of human alert fatigue. But it is a very powerful thing to bring a human being in when this non-deterministic system has the possibility of taking damaging action.
Wonderful. Well, Dan, first and foremost, I want to thank you for helping us unpack what secure identity looks like in a world where AI agents are becoming some of our most active users. As organizations begin integrating MCP-enabled systems and autonomous tools, there's clearly a lot to consider around non-human identity, authorization boundaries, and zero trust architectures.
I did want to say, if anyone did have a further question — if we didn't get to your question during today's session, the FusionAuth team will follow up. And if you want to learn more, please check out the resources shared today as well. Dan, before we wrap up, I'd love to hand it back to you to share how attendees can continue the conversation and learn more.
Yeah, we're at fusionauth.io, so you can definitely reach out to us there. And if you would like a free paper about securing autonomous agents, it's a technical framework that is going to offer you a practical framework for securing non-human actors. You can visit fusionauth.link/dzone-agents. We'd love to help educate you around the best practices for securing these exciting new — but not totally different than some of the things we've seen in the past — kinds of systems.
Well, again, thank you Dan, and thank you to everyone who joined us today. Keep an eye on your inbox for the on-demand recording. But for now, we hope to see you at a future DZone webinar.
Thanks everybody. Have a wonderful day.
