In the last post I argued that you can’t MFA an AI agent: every authentication factor we have assumes a persistent, physical person, and an agent is an abstraction running in a person’s security context. The uncomfortable conclusion was that most organisations don’t verify agents at all. They delegate, and they hope.
This post is the constructive half. The primitives for doing this properly exist today, most of them are open source, and you can learn every one of them in a homelab before anyone lets you near production. What follows is the toolbox as it stands in mid-2026.
Not all agents are the same problem
“Agent” is doing too much work as a word right now. There are at least three different things hiding under it, and they carry completely different identity risks.
Embedded copilots are the assistants baked into products you already own, with Copilot in Microsoft 365 the obvious example. They run as the user by design; that is the product working as intended, and you cannot re-architect it. What you can control is what the user can reach, because the copilot inherits every over-grant that person has accumulated. For this tier, identity hygiene for humans IS the agent control.
Citizen-developer agents are the new shadow IT. A team lead wires something up in a low-code tool on a Friday afternoon, authenticates it with their own account, and it works, so it stays. It runs as its maker from then on, surviving their role changes and sometimes their departure. We have watched this film before with Excel macros and unsanctioned Power Automate flows, except a macro could not email a supplier or approve a request on its own initiative. This tier is where sprawl compounds fastest, because the people building these agents are, quite reasonably, not thinking about identity architecture at all.
Designed agents are built as engineering artefacts: on frameworks like the ones below, on Azure AI Foundry, or in Copilot Studio when it is treated as a development platform rather than a toy. These can run in their own context, as their own principal, with scoped permissions and a separate audit trail. Everything in this toolbox assumes you want to build this kind.
The differentiator is not the technology; the same low-code tool can produce either of the last two. The differentiator is whether anyone made a decision about the agent’s identity on the day it was created, because that decision is almost never revisited afterwards. Which is the joiners, movers and leavers problem all over again, except the joiner is software and nobody logged the join.
The design goal: agents as first-class principals
The fix is conceptually simple. An agent should stop being an invisible passenger on a human identity and become a principal in its own right:
- Its own identity, so the audit log names the agent, not the person it works for.
- Its own permissions, scoped to the task, not inherited wholesale from a human who has accumulated ten years of access nobody revoked.
- Its own credentials, short-lived and automatically rotated, because a long-lived secret in a config file is just a password with better branding.
- Its own lifecycle, with an owner, a review date and an off switch. Agents need a joiners, movers and leavers process more than people do, and people barely have one.
That is the whole philosophy. Everything below is implementation.
What Microsoft is building, in the open
Five open-source projects worth your attention, all on Microsoft’s GitHub, all inspectable before you trust them. That matters: this is infrastructure for trusting software actors, and you should be able to read it.
Agent Framework is the orchestration layer: an open-source system for building and running production AI agents and multi-agent workflows in Python and .NET. It is where the agents come from; the rest of the list is how you govern what it produces.
Entrabot is the one that made me sit up. It gives a device-local agent its own Entra Agent ID and Agent User, so the agent signs in as itself, with certificate-backed authentication, rather than piggybacking on your token. This is Microsoft’s Agent 365 direction in working code: agents as first-class principals in the directory, with attribution and authorisation controls of their own.
Identity-SPIFFE is a working prototype of agent-to-agent authorisation: Entra Agent Identity combined with SPIFFE/SPIRE workload identity, enforced by sidecars with mTLS, RBAC and JWT validation, federated across Azure, GCP and GitHub Actions with no shared secrets. If your estate is multi-cloud, this is the shape of the answer.
Agent Governance Toolkit is the control plane: zero-trust agent identity via SPIFFE, DIDs and mTLS, tamper-evident Merkle-tree audit trails, and a deterministic policy engine that denies prohibited actions before they execute. That last part is the important bit. Prompting an agent to behave is a suggestion. A policy engine that makes the action structurally impossible is a control.
Autonomous Identity Hardening with Entra Security Agents is the defender’s side: a lab for building a SOC agent that cross-references sign-in logs against high-risk watch lists, classifies threats against MITRE ATLAS, and audits your Conditional Access policies for gaps and unauthorised exclusions. Yes, that is an agent auditing the controls that govern agents. The recursion is the point: at machine speed, only machines keep up.
The rules that outlast the tooling
Products will churn. These principles won’t:
- One agent, one identity. Never let two agents share a principal, for the same reason you never let two admins share an account: attribution dies.
- Scope to the task, not the owner. The agent that reads your calendar does not need your mailbox. Delegation should be a narrow beam, not a floodlight.
- Short-lived everything. Certificates and tokens that expire in minutes turn a stolen credential from a skeleton key into a fast-decaying inconvenience.
- Separate the audit stream. If agent actions and human actions land in the same log under the same name, you have already lost the investigation that hasn’t happened yet.
- Deny before execution. Guardrails that argue with the model are advisory. Policy that sits outside the model and blocks the call is enforcement. July’s sandbox-escape disclosures showed exactly why that distinction matters.
- Give every agent an owner and an expiry. An agent nobody owns is an insider nobody employs.
Learn it in the homelab first
Every primitive above has a free, self-hosted equivalent you can run this weekend, and the concepts transfer directly:
- Stand up SPIRE on a k3s cluster and issue SPIFFE identities to two workloads, then make them talk over mTLS. That is agent-to-agent identity in miniature.
- Create a dedicated service account for one automation you currently run under your own user, scope it down until it breaks, then add back only what it needs. That exercise teaches least privilege better than any course.
- Split your audit logging so the automation’s actions land in their own stream, and notice how different your own log suddenly looks.
- Then, if you live in the Microsoft world, take Entrabot or the governance toolkit apart and map what they do onto what you just built by hand.
Full disclosure: I am slowly assembling my own team of agents in the homelab, and the design rule from day one is that each one gets a discrete identity. Even at this small scale I can feel the pull the other way: it is always quicker to let a new agent borrow an existing credential than to mint it a proper one. That pull, multiplied across an enterprise, is exactly how the sprawl in this post happens. I am building mine out against this toolbox, and I will write up what breaks.
The follow-up problem is the human one: what happens to your users when agents start triggering authentication prompts and consent screens as a matter of routine? That is the approval reflex, and it is where a decade of security awareness training starts to come undone.
ReadTheManual is run, written and curated by Eric Lonsdale.
Eric has over 20 years of professional experience in IT infrastructure, cloud architecture, and cybersecurity, but started with PCs long before that.
He built his first machine from parts bought off tables at the local college campus, hoping they worked. He learned on BBC Micros and Atari units in the early 90s, and has built almost every PC he’s used between 1995 and now.
From helpdesk to infrastructure architect, Eric has worked across enterprise datacentres, Azure environments, and security operations. He’s managed teams, trained engineers, and spent two decades solving the problems this site teaches you to solve.
ReadTheManual exists because Eric believes the best way to learn IT is to build things, break things, and actually read the manual. Every guide on this site runs on infrastructure he owns and maintains.
Enjoyed this guide?
New articles on Linux, homelab, cloud, and automation every 2 days. No spam, unsubscribe anytime.
