Skip to content

AI Agent Security

AI agent security for the agents you already run and the ones your teams are building.

Your teams have built agents in Copilot Studio, Microsoft Foundry and custom code, and connected them to SharePoint, email and business systems through connectors and MCP servers. We find out what each agent can reach and do, set up the security controls that new agents inherit, and keep testing them as models and agents change.

Updated November 2026

The problem

Why AI agents need a security review of their own.

Agents act with real access

An agent reads content and then acts with whatever access it holds: a service principal, an OAuth token with broad scopes, or the connection of the person who built it. Copilot Studio warns that an agent shared with the maker's own credentials lets anyone who uses it act with the maker's access.

Instructions hide in documents and email

A language model cannot reliably tell its user's instructions from instructions planted in a file, an email or a tool result. In June 2025 researchers showed that one crafted email could make Microsoft 365 Copilot send data out through images it fetched on its own (EchoLeak, CVE-2025-32711). Microsoft fixed it on its side.

Agents reach more data than anyone meant

An agent that acts for a user sees what that user can open, and years of sites shared with the whole company make that a lot. Agents built in Microsoft Foundry before agent identities arrived share one project identity, so every agent in the project has the same permissions.

MCP servers and connectors widen the reach

Each MCP server or connector adds tools the agent can call and text the model reads. A server can change a tool's description after you approve it, and in September 2025 the npm package postmark-mcp began copying every email sent through it to an attacker after 15 clean versions.

Why now

Why now: OpenAI released GPT-6 Cyber on 5 November 2026.

On 5 November 2026 OpenAI released GPT-6 Cyber, a model tuned for security work. OpenAI says it rated the model Critical for cybersecurity under its Preparedness Framework, its highest risk level for cyber capabilities. It is limiting access to vetted customers in Daybreak Red, its program for exploit development and authorized security testing. OpenAI also says its researchers used the model to find 81 previously unknown high-severity vulnerabilities in Firefox, and Mozilla has started fixing them.

For a company that runs agents, the practical question is what someone with tools like this could reach through them. Many of the agent incidents of 2025 and 2026 needed no software bug, only an agent with too much access reading text an attacker wrote. The audit below answers that question for each agent you run.

Security audit

AI agent security audit, for agents already running.

We review the agents in scope, whether built in Copilot Studio, in Microsoft Foundry (formerly Azure AI Foundry) or in your own code, together with the MCP servers and connectors they call. We work with the access your IT lead grants and run attacks only where you approve them in writing. The audit ends with ranked findings and a remediation plan.

Inventory and owners

Every agent we can find, from the Agent Registry in the Microsoft 365 admin center, Power Platform environments, Foundry projects and your code repositories, each with a named owner, its purpose and who uses it. Agents without an owner go to the top of the findings.

Open

Identity and permissions

How each agent signs in and what it is allowed to do: service principals, OAuth scopes, connections that run on the maker's credentials, and Microsoft Entra Agent ID where your agents use it. We compare what each agent may do with what its task needs.

Open

Data each agent can reach

SharePoint and Microsoft 365 content shared wider than intended, the knowledge sources and connectors behind each agent, and the findings in Microsoft Purview Data Security Posture Management (DSPM, which replaced DSPM for AI) where your licenses include it.

Open

Testing for injection, misuse and leaks

Prompt injection through documents, email and tool results, attempts to make the agent misuse its tools, and attempts to move data out through links, images, email or tool calls. Tests run against a test copy of the agent where one exists, and we record each attack that worked and what it reached.

Open

MCP servers and connectors

Which servers and connectors each agent may call, who published them, whether tool lists are pinned at approval, and whether each server accepts only tokens issued for it, as the MCP specification (version 2026-07-28) requires.

Open

Logging and audit trail

Whether prompts, tool calls and results are recorded with the agent's identity, who can read those logs, how long they are kept, and whether an SDK writes sensitive content into traces in plain text.

Open

Mapping to the frameworks

Each finding mapped to the OWASP Top 10 for Agentic Applications for 2026, the OWASP Top 10 for LLM Applications 2026, the EU AI Act duties that apply to the agent, and ISO/IEC 42001, the international standard for AI management systems.

Open

Ranked findings and a remediation plan

Findings ranked by what an attacker could reach and how likely the path is, each with the fix, an owner and the order to do it in. We take your security team through every finding, and the plan becomes the brief for the foundation work if you go on to it.

What we test

What the audit tests, and the framework item each test maps to.

The OWASP Top 10 for Agentic Applications for 2026, released in December 2025, is our checklist for agent risks. MITRE ATLAS names attacker techniques, which helps your detection engineers write rules for them.

RiskWhat we testFramework item
Instructions hidden in content (prompt injection)Poisoned documents, emails, tickets and tool results sent to the agent, to see whether it follows themOWASP ASI01 Agent Goal Hijack
Tool misuseRequests that push the agent to use a legitimate tool for harm, or beyond its taskOWASP ASI02 Tool Misuse
Identity and privilege abuseWhat the agent's credentials allow beyond its task, and what a stolen token would allowOWASP ASI03 Identity and Privilege Abuse
MCP servers, packages and tool descriptionsWho published each server, whether tool lists are pinned, and what changed since approvalOWASP ASI04 Agentic Supply Chain Vulnerabilities
Poisoned memory or contextWhether planted text in memory or retrieved content steers later sessionsOWASP ASI06 Memory and Context Poisoning
Data leaking outEvery route out of the agent: links, images, email, tool calls and pull requestsMITRE ATLAS AML.T0086, exfiltration through an agent tool call
Rogue agentsWhether you can disable an agent, revoke its tokens and block its tool calls quicklyOWASP ASI10 Rogue Agents

Security foundation

Security foundation for AI agents, before more of them go live.

The foundation is the set of controls every new agent inherits, so no team has to solve security again for its own agent. We set it up in your Microsoft 365, Azure or AWS environment, your security lead approves each change before it goes live, and your team gets a runbook to keep it current.

Agent registry and named owners

One record per agent with a named owner, its purpose, the data it reads, a risk tier and a review date, kept in step with the Agent Registry in the Microsoft 365 admin center. An agent without an owner does not get published.

Open

A separate identity per agent

Each agent gets its own identity, with Microsoft Entra Agent ID where it fits, and only the permissions its task needs. Shared service accounts and maker credentials come out of shared agents, and tokens are short-lived and scoped to one system.

Open

An allowlist or gateway for MCP servers and tools

Agents reach only the MCP servers and tools on an approved list, enforced at a gateway such as Azure API Management where that fits. Tool lists are pinned at approval, so a server cannot change what a tool says it does without a new review.

Open

Guardrails

Checks on what goes into an agent and what comes out, using Azure AI Content Safety and its Prompt Shields where you build on Azure. Prompt Shields can check documents and email for hidden instructions as well as user prompts, and we make sure that document check is on wherever agents read them.

Open

Human approval for high-risk actions

A named person approves before an agent sends email outside the company, moves money, deletes records or changes who has access. The approval screen shows the exact action and the recipient.

Open

DLP and sensitivity labels

Microsoft Purview sensitivity labels and data loss prevention (DLP) policies, so confidential content stays away from agents that should not read it and a warning or block appears before it leaves the company.

Logs in your security tools

Agent sign-ins, tool calls and alerts sent to the security tools your team already uses, such as Microsoft Sentinel, with threat protection for AI services in Microsoft Defender for Cloud where agents run on Azure. Analysts see agent activity next to everything else they watch.

Open

Incident runbook for agents

Who decides when an agent misbehaves, how to disable its identity, revoke its tokens, block its tool calls and disconnect its integrations, and what each step leaves running. We rehearse it once with your team on a test agent.

Open

From your side

What it takes from your side.

Your security lead and IT lead agree with us which admin roles we need and for how long, and remove our access when the work ends. Attacks run against a test copy of each agent where one exists, and against production only with written approval, a time window and a named contact on your side. Each agent owner spends time with us on what the agent is for and who relies on it.

Microsoft, AWS and other licenses stay on your own agreements. A few controls on this page need specific licenses, such as Purview DSPM or Conditional Access for agents, and we tell you which before you buy anything. Legal sign-off on the EU AI Act mapping comes from your counsel.

How it works

What you have at the end.

An agent inventory

Every agent with an owner, its identity, its tools and the data it reads.

Ranked findings

Each one with the evidence, the attack path and the framework item it maps to.

A remediation plan

Fixes in order, each with an owner, agreed with your security lead.

Controls in your environment

Agent identities, tool allowlists, guardrails, approvals and DLP in use, each with an acceptance test your team signed.

An incident runbook

Who decides, how to switch an agent off, and what each step leaves running.

Test results over time

Adversarial test results after each change, in a report your CISO can take to the board.

Our method

From an agreed scope to agents you keep testing.

  1. First

    Scope and sign

    We agree which agents, platforms and tests are in scope, the access we need and the acceptance criteria for the work, in writing before anything starts.

  2. The work

    Audit or build

    We run the audit and hand over ranked findings and a remediation plan, or set up the foundation controls in your environment with each change approved by your security lead.

  3. After handover

    Keep testing

    We rerun the tests when models, tools or agents change, review new agents before they are published and report to your CISO, or hand the runbook to your own team.

Compliance & security

  • Built to SOC 2, HIPAA and GDPR standards
  • EU AI Act-aligned delivery
  • Microsoft Solutions Partner

How we engage

Four ways to work with us.

The audit is the usual first step and ends with a remediation plan you confirm. Each later piece of work has acceptance criteria agreed in writing before it starts, and licenses stay on your own agreements.

Advisory

Strategy, roadmap and readiness for an AI program.

Build

One scoped workflow at a time, with acceptance criteria agreed in writing before the build starts.

Run

Managed operations after launch, measured against those criteria.

Outcome-linked terms

Commercial terms can be tied to the acceptance criteria you sign.

Every engagement starts with one scoped workflow and a written definition of done. Commercial terms are set in the statement of work.

Frequently asked

Questions buyers ask.

What does an AI agent security audit cover?

Every agent in scope and the MCP servers and connectors it calls. We record who owns each agent, how it signs in and what it may do, the data it can reach, how it responds to prompt injection and tool misuse, whether data can leave, and what gets logged. You get findings ranked by risk and mapped to the OWASP agentic top 10, with a remediation plan.

Which agents and platforms do you cover?

Agents built in Copilot Studio, agents in Microsoft Foundry (formerly Azure AI Foundry), custom agents in your own code on Azure or on AWS with Amazon Bedrock AgentCore, and the MCP servers and connectors they use. Agents your staff build in Copilot Chat are in scope when they reach company data.

Will you attack our production agents?

Only with your written approval. We prefer a test copy of each agent with the same tools and permissions. Before any test touches production we agree the test cases, the time window and a contact on your side, and the test payloads use planted data instead of real records.

How is this different from a penetration test?

A penetration test looks for flaws in applications, networks and configuration. An agent audit also tests what the model does with text it reads, such as an email that tells the agent to forward a file or a tool description that changes after approval, which a scan for software bugs will not find. We work alongside your penetration testing provider where you have one.

What is Microsoft Entra Agent ID, and do we need it?

Entra Agent ID gives an AI agent its own identity in Microsoft Entra, separate from user accounts and ordinary service principals, so each agent can have its own permissions, sign-in rules and audit trail. Copilot Studio has created an Entra agent identity for each new agent since July 2026, and new Foundry agents get their own identity with no permissions to start. Some features, such as Conditional Access for agents, need extra licenses, and we tell you which apply.

Why do MCP servers need their own review?

The Model Context Protocol (MCP) is the standard way agents call tools and company systems, and each MCP server adds tools the agent can use and text the model reads. A poisoned tool description or an over-broad token becomes a path into your systems. The current specification (2026-07-28) requires servers to accept only tokens issued for them, and the allowlists, pinned tool lists and approval for writes are up to you.

Can you set up the foundation on AWS as well as Azure?

Yes. On AWS the same controls use Amazon Bedrock AgentCore: AgentCore Identity for agent identities, AgentCore Gateway and AgentCore Policy for which tools an agent may call, and Amazon Bedrock Guardrails for content checks. The registry, approvals, runbook and reporting work the same way on both clouds.

Can you map findings to the EU AI Act and ISO/IEC 42001?

Yes. Each finding and control is recorded against the EU AI Act duties that apply to the agent, such as telling people they are dealing with an AI and, for high-risk uses, logging and human oversight, and against ISO/IEC 42001, the international standard for AI management systems. Your compliance team and auditors get a controls map, and legal advice stays with your counsel.

Research paper

The six-layer AI governance stack: Governance that ships, not governance that stalls

AI governance in six layers, installed as running systems instead of policy binders.

Read the paper
Get the designed PDF

Which of your agents should we look at first?

Every engagement starts with one scoped workflow and a written definition of done. Commercial terms are set in the statement of work.

  • Built to SOC 2, HIPAA and GDPR standards
  • EU AI Act-aligned delivery
  • Microsoft Solutions Partner