In this session, Patrick Parker, Founder and CEO of EmpowerID, presents a real-world approach to discovering, governing, and controlling AI agent identities through continuous visibility, policy-based access governance, and risk-aware authorization. Attendees will gain practical insight into how organizations can extend identity governance principles to agentic AI environments while maintaining accountability, Zero Trust enforcement, and operational control at scale.
Practical guidance is offered for getting agents into production without losing control, starting with a warning to move slowly with focused use cases and to avoid building an “agent mesh” unless there is a specific need. Agents should be clearly defined, small in scope, and equipped with explicit tools, guardrails, and capabilities matched to specific user needs. Control should be achieved less by trying to contain where agents originate (since they can appear from anywhere) and more by governing what they can access and do inside the environment.
Four key moves are proposed. First, establish a Model Context Protocol (MCP) strategy—MCP is presented as a common interface for exposing agent tools (actions), resources (data access), and prompts, making it the “front door” to internal systems. By governing MCP-exposed resources and actions, agent owners must register within the security boundary to do anything meaningful. MCP design should be driven by business usefulness rather than mechanically converting REST APIs into MCP endpoints, which is described as creating confusion and poor usability.
Second, “gate the verb” by enforcing real-time authorization at execution, because agent behavior from registration to runtime is not deterministic and can combine capabilities in unexpected ways. Third, “hide the keys” by preventing agents from holding user tokens needed for many human-replacement automations (email, OneDrive, etc.). Instead, a gated executor should use the token to perform an authorized action and return only the results to the agent, enabling fine-grained control and preventing runaway misuse. Fourth, “prove the chain” by capturing immutable, non-writable “receipts” at the execution choke point (such as an MCP gateway), since traditional system logs often cannot reconstruct the causal chain that led to an action; this is framed as essential for forensics and potential legal disputes. A final principle cautions against overusing LLM non-determinism for deterministic business processes: keep processes predictable and use agents for well-scoped steps within them rather than re-planning everything from scratch each time.
Hello, is it on? Okay, okay, great.
How many, I'm just curious, how many of you are developing agents? Maybe raise your hand if you're developing agents.
Couple, couple, couple. How many of you use cursor or cloud code? Anything like that?
Okay, cool. Okay, so this is a quickie. It's just 10 minutes. It's just practical advice from the field. Looking at Martin's topic, which gave us a lot of insight, I mean, one thing just right off the bat. One thing right off the bat, start slow with focused use cases. Avoid an agent mesh unless you actually need it for something specific. Don't even think about that right now. Have clearly defined agents that have specific tools, guardrails, capabilities, and that specific users can use specific agents because that's what they need to use, and that's it.
Keep it discreet, keep it small, keep it tight. So, but in this, it's four moves to get agents in production without losing control.
So, number one is, and you saw it on Martin's diagram. And so, MCP, model context protocol developed by Anthropic. It's the lingua franca, it's the natural language for agents to be able to consume resources.
So, in model context protocol, you can expose tools, which are actions that the agent can perform, like creating a user, editing a user. You can expose resources, which is access to data. You can expose prompts, and there's some other new things. But the one main thing is that if you have control in your environment over your agents, well, first of all, you probably won't. They can pop up from anywhere. But the one thing that you should control are the resources that the agents need.
So, the agent will pop up, but if you have governed, controlled access to the systems and the actions that they need, they will come knocking on your door to register their agent because it won't be able to do anything if it doesn't have access to your system. So, you really should have an MCP strategy. An MCP strategy where their vendors are developing MCP to expose their systems, but your own internal systems, you should have an MCP strategy about how are you going to expose your internal systems to agents. And that will be the front door.
And that's the front door that they cannot get around, so they have to register their agent into your security boundary in order to be able to access those MCP tools that you provide. And so, that's your one way to control it.
So, you should have an MCP strategy because you want to control, map the appetite. So, map out what are the things in your environment that the agents are going to need to access in order to produce automation. And secure those and wait for the agent owners to come knocking because don't let them access the systems without them.
So, that's a key thing. And don't mistake your MCP API for a REST API. Just taking a REST API and running the FAST API to MCP and turning it into an MCP just makes a mess. MCP need to be designed for more of a business perspective to be useful rather than just mass converting everything. The next one is gate the verb.
So, you really need to have authorization over what they are allowed to do. An agent, it's nice to have the agents registered, it's nice to understand information about the agent, but from that point until runtime, it's not deterministic.
So, you actually have to have authorization at the execution time of what they're doing. You have to have real-time authorization to say, okay, it's doing something we never imagined it could do, but it put together this series of capabilities to do this.
So, you have to be able to authorize at the moment of execution. That's your control point, basically. The third one is, and this is a huge mistake, agents, most systems to automate human work, the APIs do not exist for the traditional backend service identity. They need the user. To check your email, it needs a user token. You can't do a fancy on behalf of token or some type of backend exchange. To access your email, you need a user token, your Gmail, your OneDrive.
So, if you're looking to replace human activities and automate them via agents, the agents need user tokens to be able to do that. But the worst thing you could do, let's say you're Microsoft 365, is to give the agent your token because that's the whole token and the agent's non-deterministic.
So now, it could literally do anything that you could do when your intent was to have it read your email, but it has the whole token. There's nothing stopping it from doing everything, mass emailing all your email, deleting your mailbox.
So, hide the keys means that you need to have a system in place where you authorize the agent to perform the action, like reading your email, and then it has a way to call to execute that, and the executor can use the token, perform the action, and return the data. So basically, do not give your agents tokens, give them the result of the calls that they needed to make. And that way, you have fine-grained authorization because the agent doesn't have the token and it can just run wild. It's through a gated mechanism. And the last one is, prove the chain.
So, if you're going to, there will be lots of legal lawsuits, consequences, because the agent did something that wasn't predicted, and you're going to have to have proof of what it did. Now, if you rely on today's logging technology, the end systems, like Active Directory or SAP, they don't know the chain of events that led to that action. They just see that Patrick deleted this object or this database.
So, if you want to prove the chain, you have to log at the point of execution. So again, this goes back to your MCP infrastructure. If you have, maybe, a gateway protecting all of your MCP tools, and then that's your execution choke point, then you know, at the moment of execution, the authorization data. Was it authorized? Which agent? Which user? Which policy? Which action? And you know the context.
So, you can actually have a receipt, not a log, and a receipt is something that is non-writable, immutable, and that proves the chain of actions so that you could use it in court to say, how did we get here? And we use it for forensics.
So, let the agents think, govern what they do, but if you don't have receipts, you don't have trust. And one general thing is, do not overwork the LLM because if you have a process that is deterministic, like onboarding a contractor, don't have it non-deterministic and let the agent figure it out every single time.
Agents, there's a range of completely non-deterministic to completely static, and you don't have to choose one or the other. You can have deterministic processes that use agents within the process to execute or to perform steps in a process.
So, don't think everything's now just this amorphous, I'm gonna ask it to do something and it's gonna imagine the plan from scratch every time. That's a big mistake. You still need your business processes to be predictable, but you want the automation from the agent. And that's it. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .
See All Locations
See All Locations
