Autonomous agents that read mail, post in Teams and edit SharePoint are arriving in enterprise tenants faster than the controls around them, and each one is a new non-human user that takes instructions from any text it reads. Treat it like an untrusted contractor with admin tools: contain it, log it and make it stoppable, and design those controls in before it is switched on.
This is the pattern we design to when a client wants to run a self-hosted autonomous agent in their Microsoft estate. It comes from scoping and architecture work, not a finished build we can point to.
What “caging” means
We use “cage” for a short list of properties that must all be true before the agent touches real data:
- it has its own identity, with only the permissions its use case needs
- it runs in an isolated network with no inbound access and allow-listed egress
- a policy layer, separate from the model, decides which actions it may take
- every action lands in the SIEM
- consequential actions wait for a human
- someone can stop it quickly, and has practiced doing so
The model is not part of the security boundary. Everything below assumes the model will at some point do something it was told not to.
A dedicated identity per agent
Each agent gets its own identity, never a shared account or a person’s credentials. There are three realistic shapes:
- A workload identity (a managed identity, or workload identity federation) has no password to steal and no MFA to engineer around, and fits agents that call APIs on their own behalf. Basic features are free; Conditional Access for workload identities needs a premium license and excludes managed identities.
- A dedicated user account fits agents that must act as a member of a Teams channel or SharePoint site. It brings a license, an MFA approach for unattended sign-in, a reviewed Conditional Access exception, and a joiner-mover-leaver process for a user who is not a person. In return, its activity appears in the same sign-in and audit logs as any employee’s.
- Microsoft Entra Agent ID, now generally available, adds identity types built for agents, with agent-specific Conditional Access and governance. Confirm your runtime supports it, and which admin features are still in preview, before designing around it.
Whichever you choose, scope permissions to the use case and keep any refresh tokens in Key Vault, readable only by the agent’s runtime identity.
Network isolation
The agent runs in a container with no inbound endpoint. Its subnet denies by default, and egress routes through a firewall with a short list of allowed destinations: identity sign-in, Microsoft Graph, the model endpoint, the vault and the log ingestion endpoint. Package registries are reachable from the build pipeline but not at runtime, so a compromised dependency cannot fetch a second stage. The vault, log workspace and storage sit behind private endpoints.
The container baseline is ordinary hardening, applied without exceptions:
user: non-root
root_filesystem: read-only # writable paths are named volumes
base_image: minimal, pinned to a release digest
ingress: disabled
egress: firewall only
resources: cpu and memory limits set
sandboxed_execution: true
Resource limits are a security control too: a looping agent should run out of headroom before it floods a channel.
A policy layer the model can’t talk its way past
Many agent runtimes control who may talk to the agent through per-sender allowlists; few control what it may do. We put an allow/deny layer between the agent and its tools, with deterministic rules in a policy language such as Rego or in plain JSON, not in prompt instructions. Commands are allow-listed verbs. The agent responds to mentions, not to every message. File drops go to one library and accept only allowed file types. A denied action is logged and can raise an alert.
Consequential actions, such as sending outside the organization, changing permissions or deleting content, pause for human approval in the originating channel, and both outcomes land in the audit trail.
Prompt injection arrives through tools and data
The attack is rarely someone typing “ignore your instructions”. It is a document the agent reads, a message it summarizes, or a ticket it triages: every source the agent reads is an input to its instructions. A threat model should cover at least:
- injection through a chat message, and through file content
- data exfiltration hidden in the agent’s own replies
- a stolen refresh token replayed from outside the network
- the agent calling APIs outside its intended scope
- a malicious package pulled in at runtime
- the system prompt leaking through crafted questions
Each scenario needs a named control: a firewall rule, a policy rule or a specific alert. “We have Defender” is not a mitigation, and per-sender allowlists do not stop injection that arrives through a source the agent may read.
Log everything, and know your latency
Bring every relevant log into the one workspace the SOC already uses: container output, identity sign-ins and the unified audit log, firewall flows, application logs, and the agent’s own prompt and action trace. Start with alerts on denied egress, unexpected sign-in locations, policy denials and Graph permission use outside the expected set.
Two cautions. First, the unified audit log is not real-time. Microsoft documents that records for core services such as Exchange, SharePoint and Teams are typically available 60 to 90 minutes after the event, other services can take longer, and no delivery time is guaranteed. It is for investigation, not for stopping an agent in the act; near-real-time detection needs the agent’s own trace, which many runtimes don’t export without a logging proxy. Second, model inputs and outputs contain whatever users pasted. Redact personal data before prompts and responses are logged or stored, and turn off request-body logging at the API gateway.
A kill switch you have actually pulled
A kill switch is a runbook, not a button on a slide. It names who can trigger it, which credentials get revoked and rotated, and how the deployment is torn down and rebuilt. Rehearse a full teardown before go-live, and test injection, exfiltration, token replay and sandbox escape. A test passes when a control catches it, not when nothing visibly happens.
The agents you didn’t build
The agent you are carefully caging is probably not the only one in your tenant. Low-code builders let business users publish agents with connectors to mail, files and line-of-business systems, often running on the author’s own connections. Treat that estate as an attack surface: inventory every agent, record what each can reach, and try to make it misbehave. Then apply the platform’s controls, test again to see whether each one actually helped, and repeat the review on a schedule.
Separate the design from the build
A first phase expected to deliver the design, a hardened environment, a running agent, monitoring and a tested kill switch at once is most of a production build. We would rather start with a design and a minimal proof, then scope the full build from what the design finds.
How we can help
If you are planning to run an autonomous agent in your tenant, or suspect you already have more agents than anyone has counted, we can help design the controls and scope the work before anything is switched on. Contact us to talk it through.
