Read it as an identity book, not a config guide
Thomas De Vos
So far I have been extremely impressed by Securing Enterprise AI Agents. Go in expecting an Agent 365 configuration walkthrough or a list of Claude best practices and you will be disappointed. It sits higher than that.
It looks at how identity is changing and what an organization has to do to be ready for it. Which is the conversation most tenants are skipping while they roll out agents anyway.
Thank you to Sayantani Saha at Packt for reaching out and sending me an early review copy (ERC) for a first look.
The people problem was there before the agents
At Ignite last year I wrote about whether MSPs are ready for an agentic future. My doubt comes from the MSP side of my career, where I worked through a lot of identity led initiatives. What I took from them is simple. Humans are fallible. We mean well, but our intent and our actions don't always line up.
I kept fixing environments with weak identity posture, knowing identity is where attacks start and has been for years. Former employees still licensed, still holding higher permissions. Owners of Enterprise apps nobody had used in years. Hundreds, sometimes thousands, of Enterprise apps where almost no one could tell you which APIs were approved or who had access.
The author describes the same drift with MCP servers. Without lifecycle discipline, three years in you have a hundred of them. Half have no owner, twenty have been forgotten, ten hold credentials that rotated out of the secrets store, and five are findable by a determined attacker. His point is that the proliferation is what catches teams off guard, which is exactly how Enterprise app sprawl felt in the tenants I fixed.
Agents inherit every weakness users have
Agents are exploding, and they carry the same limits users do. They just speed everything up. Sprawl and governance headaches that took years to build with human accounts can show up in a quarter.
Done correctly, agents push efficiency. I can't picture my day without them anymore. Done carelessly, you pour an accelerant on a pile of old problems.
Why can't an agent just run as the user? The book gives four reasons. A user approved a conversation, not every action the agent takes inside it. Sessions have no tight bound. The lifetime of a human login is wrong for an agent task. And it muddies the audit trail, because every downstream log shows the user as the actor. The agent is a credentialled mediator, and the book wants it treated that way.
Risk is framed around four authorities an agent can hold: read, plan, act and remember. They multiply instead of adding up, and the blast radius is what you answer for when one goes wrong.
What the book actually covers
It touches almost every architecture and governance question an organization should be asking, but the one that cuts deepest is this: what does security and auditing look like once the identity making decisions isn't human anymore?
Identity and tool access
Chapters on MCP, agent identity and tool calls cover how agents authenticate and what they are allowed to reach.
Knowledge governance
Retrieval, permissions and governance of the data an agent can see, treated as a security problem.
Run and respond
Deployment patterns, policy as code, incident response and ongoing operations for agents in production.
A readiness checklist
The final chapter turns the book into questions you can walk your own organization through.
Every agent answers to a human
Agents have to be secure by design. They don't just spring up and get immediate access. The right people and departments approve it first. And for every human you may have tens or hundreds of agents, so every one needs a person who governs it and owns its long term success, including what it does and what it can reach.
Microsoft's own guidance lines up with this. Entra Agent ID requires every agent identity and blueprint to have at least one sponsor, a human or supported group with business accountability for the agent's lifecycle. If the sponsor leaves, sponsorship transfers to their manager. Microsoft also says to build agents inside the Agent ID framework instead of as plain app registrations or service principals.
The Microsoft Learn governance page for agent identities was still labelled preview when I checked it on 27 October 2026. These pages move fast. I wouldn't lock a client design to this until it hits GA.
Now picture the yearly audit. The HTML report comes up and shows 800+ agents with no owner. Nobody can account for the automation each one performs. Those blank stares are avoidable.
Every agent gets three named owners: a business owner, a technical owner and a risk owner. The book's example inventory entry for its sanctions screening copilot names a person in each role. Four artefacts back it up: an inventory, a classification, an approval record and a monitoring posture. The cadence runs weekly for inventory changes, monthly for per tier reviews, quarterly for the operating model and annually for a full rewrite of it.
Connectors get a lifecycle with seven states, from proposed through designed, reviewed, deployed and versioned to deprecated and retired.
Delegated tokens carry both the user and the agent, expire in minutes, and the verifier rejects a bare user token. The audit log records both identities. Each agent also gets a written contract declaring owners, tier, identity, data scopes, tools and approvals, and the book runs a tabletop that tests whether you can revoke an agent within five minutes.
Data governance pushes the pyramid up
Look at the pyramid again. Data governance drives the requirements further toward the top. Purview has usually been an afterthought, something you bolt on after the rollout. With agents it has to be part of the security process from the first day.
Microsoft frames it the same way. Its Copilot controls guidance starts with data security: find overshared data, remove organization wide site access, and clean up inactive or ownerless SharePoint sites so that Copilot and agents don't inherit the mess.
The chapter opens with a composite story that reads like a tenant audit. An agent ends up reading from twelve sensitive document collections, including drafts, retired documents that were never removed, and a corner of SharePoint nobody could explain. Three indexes were leaking restricted data. The author notes that the story is a composite of several engagements.
Permissions have to be applied at retrieval time, before ranking, using the user's identity. The book calls out retrieving broadly and filtering afterwards in application code as the anti pattern that leaks.
Classification happens at the source. Entitlements are checked at retrieval against the authoritative system. Retention is set per agent artefact, and documents move through draft, in review, in effect and retired.
The worked incident, a mortgage refund error, traces back to a sensitive document where unset classification defaulted to public. The recovery step changed the default to restricted until someone explicitly publishes. Defaults are a governance decision, and nobody was making it.
My mapping, not the book's: the controls in Chapters 11 and 13 line up with what Purview already does with sensitivity labels, oversharing reports, retention and site lifecycle management. That is why I keep saying it belongs at the start of the project.
Make it a routine, not a project
The line I keep coming back to is lifecycle. A one time cleanup gets undone in a year, and agents make a year feel like a quarter. The book ends the same way, with routines.
The final chapter is a production readiness checklist with six sections: architecture, security, evals, observability, governance and rollout. The review is a meeting, the agenda is the checklist, and the three owners attend. The author also spends time on using it to say no, which is the part I would expect most organizations to find hardest.
Rollout runs shadow, then pilot, then canary, then progressive. Stop the line triggers, like an eval drop, a jump in cost or a single high severity incident, are written down before launch.
Build time and runtime controls feed a closed loop, and every automatic action is one that takes capability away, such as revoking a token or rolling back, and every one also pages a human. Automation buys time and the person still owns the resolution.
Count the agents nobody owns
I spent years cleaning up identity messes that people made slowly. Agents make the same messes faster, and the yearly audit is the wrong place to learn that nobody owns them and nobody knows what they automate or why.
Treat every identity the way you'd want a human account treated: approved before access, owned by a person, reviewed on a schedule, and retired when it's done. Then pull your agent inventory this week and count how many don't have a name next to them. That number is where you start.