Risk quantification for AI agents does not exist as a formal discipline. When security teams are asked to score the risk of an AI agent, they typically reach for one of two tools: a CVSS score, which was designed for traditional software vulnerabilities and is a poor fit for autonomous agents; or a gut-feel risk rating (low/medium/high/critical) that cannot be compared across agents, teams, or organisations.
Neither approach is adequate. We needed something better for our own platform, so we built it. This is the Amajoni Blast Radius Score: a four-dimension, 100-point scoring model designed specifically for AI agents. We are publishing the full methodology so the community can critique it, build on it, and use it independently of our tool.
Why CVSS Does Not Work for AI Agents
CVSS (Common Vulnerability Scoring System) was designed to score software vulnerabilities — buffer overflows, injection flaws, authentication bypasses. It models exploitability (how easy is it to exploit the flaw?) and impact (what happens to confidentiality, integrity, and availability if it is exploited?). This model assumes a fixed vulnerability in fixed code that produces a predictable outcome when exploited.
AI agents are not fixed code with predictable exploit outcomes. The 'vulnerability' in an AI agent is not a specific code flaw — it is the combination of natural language flexibility, tool access, and the absence of semantic guardrails. The 'exploit' is not a specific input that produces a specific output — it is any input that persuades the agent to take an action the attacker wants. The outcome varies with the attacker's creativity, the agent's capabilities, and the permissions attached to its execution role.
CVSS asks: how bad is this vulnerability? The right question for AI agents is: how bad is the worst thing this agent can be made to do? Those are different questions, and they need different answers.
Additionally, CVSS does not account for call volume. A CVSS score treats a vulnerability identically whether it affects a system that processes 1 request per day or 10,000. For AI agents, call volume is a material risk factor: a high-volume agent that is compromised is a high-rate exfiltration or high-rate disruption event. Volume belongs in the score.
The Four Dimensions of Blast Radius
The Blast Radius Score is built on four dimensions, each scored on a sub-scale. The dimensions were chosen because they represent the maximum damage categories that a compromised AI agent can cause, and because they can be assessed objectively from the agent's configuration and IAM permissions without requiring subjective judgement calls.
Dimension 1: Data Sensitivity (0–30 points)
Data Sensitivity measures the sensitivity of the data the agent can access through its tool calls and IAM permissions. The underlying question is: what is the worst data that could be exfiltrated if this agent is fully compromised?
Data Sensitivity scoring: 0–10 points: Access to internal operational data with no customer PII or financial data (logs, metrics, configuration). 11–20 points: Access to customer PII (names, emails, addresses) or internal financial data. 21–30 points: Access to financial account data, identity documents, payment card data, health records, or credentials for other systems. Score reflects the highest-sensitivity data accessible — not an average.
Dimension 2: System Impact (0–30 points)
System Impact measures the damage the agent can cause to systems and infrastructure through its write permissions and compute access. The question is: what is the worst infrastructure damage if this agent is fully compromised?
System Impact scoring: 0–10 points: Read-only access to systems. Write access limited to logging or non-production resources. 11–20 points: Write access to production data stores (databases, S3 buckets with meaningful content) or the ability to invoke other Lambda functions or services. 21–30 points: Ability to modify IAM roles or policies, create infrastructure, delete production data, or access credentials that enable access to additional systems (ssm:GetParameter /prod/*).
Dimension 3: Financial Impact (0–25 points)
Financial Impact measures the direct financial damage an attacker can cause through the agent's capabilities. This dimension is unique to AI agents — traditional vulnerability scoring does not separately account for direct financial action capability.
Financial Impact scoring: 0–8 points: No direct financial action capability. Agent cannot initiate transactions, provision resources, or trigger payments. 9–17 points: Limited financial action — can trigger refunds below a threshold, provision low-cost resources, or initiate transfers within defined limits. 18–25 points: Significant financial action — can initiate large transfers, provision expensive cloud resources without limit, access payment processing systems, or trigger bulk refunds.
Dimension 4: Operational Reach (0–15 points)
Operational Reach measures the agent's ability to affect systems and users beyond its immediate context — specifically, its call volume (a high-volume compromise is a high-rate incident) and its ability to affect other agents or downstream systems.
Operational Reach scoring: 0–5 points: Low volume (under 10 calls/hour). No ability to invoke other agents or systems. 6–10 points: Medium volume (10–100 calls/hour) or ability to invoke 1–2 downstream services or agents. 11–15 points: High volume (over 100 calls/hour) or ability to invoke a large number of downstream services, or acts as an orchestrator for other agents.
The Scoring Formula
Blast Radius Score = Data Sensitivity + System Impact + Financial Impact + Operational Reach Range: 0–100 Risk bands: 0–24: LOW — Minimal blast radius. Monitor. 25–49: MEDIUM — Notable blast radius. Review permissions quarterly. 50–74: HIGH — Significant blast radius. Remediate within 30 days. 75–100: CRITICAL — Maximum blast radius. Immediate remediation required. Example calculation — prod-customer-support-agent: Data Sensitivity: 22/30 (accesses customer PII + order financial data) System Impact: 18/30 (write access to orders DB + can invoke refund Lambda) Financial Impact: 14/25 (can trigger refunds up to R500 per transaction) Operational Reach: 11/15 (180 calls/hour, invokes 2 downstream services) ───────────────────────────────────────────────────── Blast Radius Score: 65/100 → HIGH Example calculation — dev-log-parser-agent: Data Sensitivity: 4/30 (accesses application logs only, no PII) System Impact: 3/30 (read-only CloudWatch access) Financial Impact: 0/25 (no financial action capability) Operational Reach: 2/15 (3 calls/hour, no downstream invocation) ───────────────────────────────────────────────────── Blast Radius Score: 9/100 → LOW
How We Validate the Scores
Score validation is the hardest part of any risk quantification methodology. We validate Blast Radius Scores through three mechanisms. First, we compare scores to incident data — when a real AI agent compromise occurs (in public disclosures, in bug bounty reports, or in controlled red team exercises), we check whether the affected agent's Blast Radius Score predicted the actual damage envelope. Our current dataset is small but directionally consistent.
Second, we perform adversarial scoring: for each agent in our test environment, we ask a red team to assess the maximum damage they could cause given the agent's IAM permissions and tool access, then compare that assessment to the computed score. We are targeting a correlation above 0.80 between adversarial damage estimates and Blast Radius Scores.
Third, we track score drift over time. An agent whose permissions expand should show an increasing Blast Radius Score on the next scan. If the score does not reflect documented permission changes, the scoring inputs are incorrect. We use this as a quality control check on our IAM parsing logic.
Why Blast Radius Beats Risk Score Alone
Most AI agent platforms expose a 'risk score' or 'security rating' that is computed from a weighted combination of factors. These scores are useful but incomplete. A risk score tells you how risky an agent's configuration is relative to best practices. A Blast Radius Score tells you how bad the worst-case outcome is if the agent is actually compromised.
An agent running in a development environment with an overly broad IAM role might score high on risk (bad configuration) but low on blast radius (no production data, no financial access, no customer impact). Conversely, an agent with a tight IAM policy but access to production payment processing infrastructure might score low on risk (good configuration) but medium-high on blast radius (the configuration is good but the data it accesses is sensitive). Both pieces of information matter. Blast Radius Score provides the piece that risk configuration scoring misses.
How to Calculate Your Own Blast Radius Score
- Step 1 — List all IAM permissions attached to the agent's execution role, including those inherited through IAM policies attached to the role and through service control policies at the account or organisational unit level.
- Step 2 — Score Data Sensitivity: identify the most sensitive data type accessible through any permission on the list. Use the bands above. If the agent can reach a table containing payment card data through any permission, score 21–30 regardless of what else is on the list.
- Step 3 — Score System Impact: identify the most impactful write or infrastructure action available. iam:PassRole or iam:CreateRole scores 21–30 regardless of other permissions. Any write to a production data store scores 11–20 at minimum.
- Step 4 — Score Financial Impact: identify the most significant financial action the agent can take in a single execution. Consider both direct financial actions (payment APIs, transfer functions) and indirect ones (provisioning expensive compute, triggering expensive batch jobs).
- Step 5 — Score Operational Reach: check call volume from CloudWatch metrics for the last 30 days. Assess whether the agent can invoke other services, agents, or orchestrators.
- Step 6 — Sum the four scores. Apply the risk band. Document the score, the date, and the specific permissions that drove each dimension. Schedule a rescore whenever permissions change significantly.
This methodology is version 1.0. We expect it to be wrong in places we have not yet discovered. If you find an edge case where the score dramatically misstates the actual blast radius, we want to know about it. Write to us at hi@amajoni.com with your case.