Microsoft’s Five AI Agent Risk Classes: A Practical Security Control Map

Microsoft’s 2026 Digital Defense Report turns the agentic attack surface into five practical risk classes: prompt manipulation, sensitive data exposure, identity compromise, excessive agency, and operational integrity. The useful lesson is not that AI needs an entirely separate security program. It is that familiar controls must now follow every agent across its prompts, memory, credentials, tools, and actions.

Published on October 1, 2026, the report describes AI systems as both a defensive accelerator and a growing enterprise attack surface. Microsoft reports that 88% of enterprises are experimenting with AI agents and that 82% of leaders plan broader rollouts within 12 to 18 months. Those figures come from Microsoft’s own report and should be read as vendor research, not as a universal measurement of every market.

This guide translates Microsoft’s five risk classes into controls a security architect, platform team, SOC, or application owner can implement and test. It also includes a safe, offline policy-audit lab that never connects an agent to a model or production tool.

What changed, and what did not

AI agents combine a model with enterprise context and the ability to act. Depending on the design, an agent may read email, query a SIEM, update tickets, call cloud APIs, execute code, or delegate to another agent. That creates a security boundary larger than the model itself.

Microsoft’s report says attackers are using AI across reconnaissance, phishing, vulnerability research, malware and exploit development, data analysis, and post-compromise work. It also provides an important qualifier: complex intrusions still commonly involve meaningful human direction. Defenders should prepare for faster and more repeatable operations without assuming that fully autonomous attacks are already the norm.

The fundamentals remain recognizable. Identity, authorization, data protection, least privilege, monitoring, testing, and secure software development still determine the blast radius. The change is that an agent can connect these domains and repeat a bad decision at machine speed. If your organization is still defining its broader model and application controls, begin with our enterprise AI security foundation. For a concrete example of filesystem exposure, see the SharedRoot container risk analysis.

The five AI agent risk classes

1. Prompt and intent manipulation

Prompt injection is not only a text-filtering problem. An instruction can arrive inside a document, support ticket, repository issue, image metadata, web result, or long-term memory. Blocking a few phrases will not establish whether a requested action is authorized.

• Label every input by trust level and preserve its origin through the workflow.
• Keep untrusted content in a data channel that cannot silently modify the system policy.
• Validate the user’s intended task independently from instructions discovered in retrieved content.
• Require output review before the output becomes a command, message, deployment, or external API call.
• Record the prompt, retrieved context, policy decision, tool request, and result as one trace.

Detection should focus on behavior as well as strings. Alert when a low-trust input causes a new tool selection, a privilege change, an unexpected destination, or a sharp increase in action count.

2. Sensitive data exposure

An agent can be technically authorized to query a source while still returning data to the wrong user or channel. Retrieval authorization must therefore consider the human requester, the agent identity, the purpose, the destination, and the sensitivity of the result.

• Enforce access at the source instead of trusting the model to hide unauthorized records.
• Scope memory to a case, tenant, or task, and set explicit retention limits.
• Inspect prompts and responses with data-loss prevention policies appropriate to the environment.
• Redact credentials, tokens, secrets, regulated identifiers, and private keys before model submission.
• Test cross-user, cross-tenant, and stale-memory scenarios in preproduction.

A useful negative test asks the agent to summarize a case it can see, then requests a second case owned by another user. The secure outcome is not a polite refusal generated by the model; it is an authorization denial produced by the data layer.

3. Identity and privilege compromise

Treat agents as non-human identities. A shared automation account makes attribution weak and revocation disruptive. A distinct identity per agent, environment, and purpose lets defenders identify the actor, limit its permissions, rotate its credentials, and disable it without stopping unrelated automation.

• Issue short-lived credentials through workload identity or token exchange where available.
• Bind credentials to the agent, workload, environment, audience, and allowed operation.
• Use mutual authentication for agent-to-agent and agent-to-tool calls.
• Remove standing administrator roles and separate read, propose, approve, and execute permissions.
• Maintain an owner, expiration date, and emergency-revocation path for every agent identity.

This is the same migration pressure seen in other non-human identities. Our GitHub App token audit guide shows how token format and lifecycle changes can expose hidden assumptions in automation.

4. Excessive agency

A tool can be safe in isolation and dangerous in combination. Reading a customer record, drafting an email, and sending a message are separate capabilities. Chaining all three without a destination check or human approval changes the risk.

• Allow-list named tools and operations instead of granting a wildcard tool catalog.
• Enforce argument schemas, destination restrictions, network egress rules, and per-run action limits outside the model.
• Require approval for destructive, externally visible, financially material, or privilege-changing actions.
• Use a dry-run or propose-only mode before enabling execution.
• Add a kill switch that revokes credentials and halts queued actions, not merely the chat session.

Runtime policy must inspect the complete proposed action. “Send message” is not enough. The decision needs the recipient, channel, data classification, attachment set, initiating user, and preceding tool chain.

5. Operational integrity

Agent behavior depends on more than source code. System prompts, tool definitions, memory stores, retrieval indexes, model versions, policies, dependencies, and deployment configuration can all change an outcome. If these artifacts are mutable without review, an attacker may alter the agent while leaving the application binary untouched.

• Version and sign system prompts, policies, tool schemas, and deployment manifests.
• Protect build and model supply chains with provenance, dependency review, and controlled promotion.
• Send audit events to append-only or otherwise tamper-resistant storage.
• Record configuration and model versions in every execution trace.
• Test rollback and recovery, including memory invalidation and credential revocation.

A deployment blueprint security teams can use

Start with inventory, not a prompt-injection product. For every production agent, document its owner, purpose, identity, data sources, memory, model, tools, credentials, network destinations, approval points, logs, and kill switch. If one of those fields is unknown, the agent is not ready for autonomous operation.

Build three control planes

1. Identity and data plane: authenticates the requester and agent, authorizes retrieval, scopes memory, and limits credentials.
2. Action plane: validates tool names, arguments, destinations, sequence, rate, and required approval before execution.
3. Evidence plane: correlates prompts, context, identity, policy decisions, tool calls, configuration versions, and outcomes in a tamper-resistant trace.

Do not let the model control these planes. The model may propose an action, but a deterministic policy service should decide whether the request is permitted. This creates a stable enforcement point even when the model, prompt, or retrieved content changes.

Monitor the joins between systems

Agent incidents often become visible only when telemetry is correlated. Join identity events with model and tool traces, API gateway logs, endpoint activity, cloud control-plane events, DLP findings, and the originating user session. High-value detections include:

• a new tool or destination immediately after processing untrusted content;
• one agent identity appearing from an unexpected workload or environment;
• retrieval from a sensitive source followed by external communication;
• action volume or tool-chain depth outside the agent’s baseline;
• configuration changes without a matching approved change record;
• audit gaps between an agent decision and the downstream system action.

Microsoft’s report argues that cross-system signal correlation is an especially valuable defensive variable. For an agent, that means the SOC needs one trace identifier that survives from user request to every tool result and final side effect.

Hands-on lab: audit a synthetic agent policy

This isolated lab checks nine baseline properties in a JSON policy. It does not call a model, connect to production, or execute any agent tool. Use a disposable directory with Python 3.9 or later. The validator uses only the Python standard library.

1. Create the sample policy

{
  "agents": [
    {
      "agent_id": "triage-agent",
      "identity": "svc-ai-triage-prod",
      "shared_identity": false,
      "allowed_tools": ["case.read", "case.comment", "intel.lookup"],
      "credential_scope": "case-triage",
      "human_approval_actions": ["send_external", "delete", "deploy"],
      "memory_scope": "case",
      "immutable_logs": true,
      "config_signed": true,
      "network_allowlist": ["siem.internal", "intel.internal"],
      "max_actions_per_run": 25
    },
    {
      "agent_id": "general-agent",
      "identity": "shared-automation",
      "shared_identity": true,
      "allowed_tools": ["*"],
      "credential_scope": "admin",
      "human_approval_actions": [],
      "memory_scope": "global",
      "immutable_logs": false,
      "config_signed": false,
      "network_allowlist": [],
      "max_actions_per_run": 500
    }
  ]
}

Save the file as agent-policy.json. The first entry represents a constrained SOC triage agent. The second is intentionally unsafe so the audit produces actionable failures.

2. Create the validator

#!/usr/bin/env python3
import json
import sys

REQUIRED_APPROVALS = {"send_external", "delete", "deploy"}

def audit(agent):
    issues = []
    if agent.get("shared_identity") or not agent.get("identity"):
        issues.append("shared-or-missing-identity")
    if not agent.get("allowed_tools") or "*" in agent.get("allowed_tools", []):
        issues.append("wildcard-tools")
    if agent.get("credential_scope") in {None, "", "admin", "global"}:
        issues.append("overbroad-credentials")
    approvals = set(agent.get("human_approval_actions", []))
    if not REQUIRED_APPROVALS.issubset(approvals):
        issues.append("missing-high-impact-approvals")
    if agent.get("memory_scope") in {None, "", "global"}:
        issues.append("global-memory")
    if agent.get("immutable_logs") is not True:
        issues.append("mutable-logs")
    if agent.get("config_signed") is not True:
        issues.append("unsigned-config")
    if not agent.get("network_allowlist"):
        issues.append("open-egress")
    limit = agent.get("max_actions_per_run")
    if not isinstance(limit, int) or not 1 <= limit <= 50:
        issues.append("unsafe-action-limit")
    return issues

def main(path):
    with open(path, encoding="utf-8") as handle:
        policy = json.load(handle)
    failed = False
    for agent in policy.get("agents", []):
        issues = audit(agent)
        if issues:
            failed = True
            print(f"FAIL agent={agent.get('agent_id', 'unknown')} issues={','.join(issues)}")
        else:
            print(f"PASS agent={agent['agent_id']} controls=9/9")
    return 1 if failed else 0

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("usage: audit_agent_policy.py POLICY.json", file=sys.stderr)
        raise SystemExit(2)
    raise SystemExit(main(sys.argv[1]))

Save this file as audit_agent_policy.py.

3. Run the audit

python3 audit_agent_policy.py agent-policy.json

Expected output:

PASS agent=triage-agent controls=9/9
FAIL agent=general-agent issues=shared-or-missing-identity,wildcard-tools,overbroad-credentials,missing-high-impact-approvals,global-memory,mutable-logs,unsigned-config,open-egress,unsafe-action-limit

The nonzero exit status is intentional when any agent fails, which makes the script suitable for a CI policy gate. This is a baseline example, not a complete authorization system. Production checks should use your actual identity provider, tool registry, data classifications, approval workflow, and policy engine.

Troubleshooting and cleanup

• JSONDecodeError: validate commas and quotation marks in agent-policy.json.
• File not found: run the command from the directory containing both files, or supply an absolute policy path.
• No output: confirm the top-level JSON object contains an agents array.

rm agent-policy.json audit_agent_policy.py

Prioritize controls by blast radius

Not every agent needs the same control depth. A read-only documentation assistant and an infrastructure remediation agent do not belong in the same risk tier. Increase assurance as data sensitivity, privilege, external visibility, autonomy, and irreversibility increase.

For an early deployment, the most valuable sequence is usually: inventory agent identities; remove shared credentials; allow-list tools and destinations; gate destructive or external actions; scope memory and retrieval; centralize traces; then red-team the joins between those controls. Measure exposure reduced, detection coverage, approval bypasses prevented, and time to revoke or contain an agent. Raw prompt-block counts and alert volume are poor substitutes for risk reduction.

Conclusion

Microsoft’s five classes are useful because they prevent teams from treating the model as the whole system. A secure agent needs defenses around instructions, data, identity, tools, and operational state. The strongest design gives the model room to propose while keeping authorization and execution in deterministic, observable control planes.

Before expanding autonomy, prove that every agent has a distinct identity, bounded data access, a narrow tool set, explicit approval points, tamper-resistant evidence, and a tested revocation path. If a team cannot answer who acted, under whose authority, with which configuration, and through which tool chain, it does not yet have an agent security boundary.

Primary sources

• Microsoft Security Insider: 2026 Digital Defense Report, published October 1, 2026.
• Microsoft: Digital Defense Report 2026 topic hub and agentic risk-class table.
• Microsoft Security Blog: Insights from the 2026 Microsoft Digital Defense Report, published October 1, 2026.