AI Agent Security

Agent Risk Assessment

Each discovered agent receives a risk rating with a breakdown of the contributing factors. The assessment is based on an agent’s configuration and components: its tools and toolsets, connected MCP servers, model, authentication, and usage. Risks are also grouped into a risk-types view that shows where each risk type sits across your whole inventory, so a security team can prioritize across many agents rather than reading one assessment at a time.

Per-agent ratings

  1. Every agent gets a rating of Critical, High, Medium, or Low.
  2. The contributing factors panel explains which risks drove the rating and why, with the description behind each risk.
  3. Risks carry an external-framework mapping (OWASP, MITRE ATLAS), so each finding can be tied back to the frameworks your security program already uses.

Risk types surfaced

  1. Excessive agency: how much an agent can do relative to its function. Examples: agents with more tools or broader permissions than their task requires, and available tools that are never used.
  2. Identity and secrets: how an agent and its components authenticate. Examples: an agent owned by a non-organizational identity, and weak or missing authentication configuration on platforms that expose it.
  3. Supply chain and provenance: where an agent’s components come from. Examples: unofficial or unverified MCP servers, MCP servers whose public code shows vulnerabilities or suspicious indicators, and components of unknown origin.
  4. Data exposure and leakage: an agent’s access to sensitive data combined with paths that data could take outward. Examples: tools that read sensitive sources feeding tools that can write externally.
  5. Governance: ownership and accountability. Examples: agents without a clear organizational owner, and shadow agents created outside sanctioned processes.
  6. Maintenance and hygiene: housekeeping that accumulates risk. Examples: inactive agents and toolsets, and disabled or unused tools left attached.
  7. Toxic combinations: individually acceptable capabilities that are dangerous together. The main example is the lethal trifecta: an agent that can read confidential data, take in untrusted content, and communicate externally at the same time. None of the three alone is necessarily alarming; together they create a path for data exfiltration.

Some risks are platform-specific because they depend on configuration only that platform exposes. For example, no-authentication and author-credential risks apply to Microsoft Copilot Studio. Where a platform exposes less detail (see discovery depth), the assessment runs on the available fields and shows what could not be assessed.

Risk severity

Agent risk severity answers one question: how close is this finding to a realizable loss event, and how large is that loss if it happens? We assess every risk against four factors:

  1. Impact: The blast radius if the condition is exploited.
  2. Preconditions: How much else has to be true before an attacker can act on it.
  3. Control strength: Whether an effective gate remains in place, such as authentication, human approval, or organizational management.
  4. Finding confidence: Whether the condition is confirmed, or indicated by signals that warrant review.

This produces five bands:

  1. Critical: The exploitable path is complete, or adversarial intent is confirmed. Deliberately rare. Examples: likely malicious code in a toolset; a toxic combination where an agent has access to confidential data, exposure to untrusted input, and a path to an untrusted destination.
  2. High: A single condition removes a security control or places an untrusted component directly in the agent’s execution path, with no further preconditions required. Examples: an agent published without authentication; a fully autonomous agent with no human gate; code execution enabled; an unknown MCP server; a tool accepting input from an untrusted source.
  3. Medium: The condition materially widens the attack surface or breaks least privilege, but requires another condition or attacker action to cause loss. Examples: write-capable tools; static credentials in toolset configuration; OAuth available but not used.
  4. Low: Hygiene and technical debt, or factors that become significant only in combination. Examples: inactive agents and toolsets; deprecated transport layers; missing parameter schemas. Informational. Present in configuration but not currently active.

Two rules matter particularly for agentic systems:

  1. Severity is inherited where an authoritative score already exists. For example, vulnerable MCP servers follow the CVSS score of the underlying CVE.
  2. Combinations escalate; scores do not sum. Individually low or medium conditions can combine into a critical finding.

Our agent risk framework structure follows established security practice and is modelled on the Common Weakness Scoring System (CWSS). CVSS is used directly wherever a finding relates to a published CVE. Risk categories and threat patterns are mapped to OWASP LLM Top 10, the OWASP Agentic Security Initiative risks, and MITRE ATLAS.

Prioritizing across agents

The Risk Posture view shows each risk type with its severity, the number of agents affected, its category, and its external-framework mapping. Reviewing the most severe and most widespread risk types first gives a clearer prioritization than reading per-agent assessments one at a time: the top risk types by severity and number of agents affected are usually where remediation effort pays off most.

Scope

The assessment is based on each agent’s configuration and components. It tells you about risk before anything bad has happened; it does not cover the risk of live behavior. Runtime protection is the separate, complementary layer — see Agent Behavior Defense — and the two are designed to be used together: posture to reduce standing risk, runtime to stop live threats.