Assurance-AI platform
Agentic AI Security Assurance
Assurance-AI evaluates agentic applications across architecture, adversarial behavior, tool authority, control evidence, and software delivery. It distinguishes confirmed security conditions from controls that cannot be verified from the available evidence.
- ConfirmedEvidence establishes the condition
- Not verifiedEvidence is insufficient either way
- Verified controlEvidence supports the control within scope
Scope and limits
Lifecycle coverage
Where Assurance-AI fits the agentic lifecycle
Stages follow the OWASP GenAI Security Project's AI Security Solutions Landscape for Agentic AI (Q2 2026). Coverage is Assurance-AI's own self-assessment, not an OWASP assessment.
| OWASP lifecycle area | Assurance-AI coverage | How it is addressed |
|---|---|---|
| Scope & Plan | Implemented | Architecture-level threat modeling for agent, multi-agent, MCP, and RAG designs: trust boundaries, identities, agent privileges, tool authority, data flows, and attack-surface mapping from supplied architecture descriptions. |
| Augment, Fine Tune Data | Not Offered | Assurance-AI does not provide a dedicated capability for training or fine-tuning data pipelines. |
| Develop & Experiment | Implemented | Repository and pipeline assessment: detection of agent, MCP, RAG, and LLM components, tool and permission analysis, workflow security, dependency evidence, and CI/CD security review. Static findings are not treated as proof of exploitability. |
| Test & Evaluate | Implemented Reference Fixture | Primary capability. Repeatable adversarial scenarios, including prompt injection, indirect prompt injection, tool misuse, and excessive agency, with response-level evaluation. Action-level evidence, vulnerable-versus-hardened comparison, guardrail validation, and retesting are demonstrated on a controlled reference fixture. |
| Release | Implemented | Assessment and validation only. Assurance-AI assesses dependency pinning, workflow and container image pinning, and whether SBOM, artifact signing, and provenance tooling appear in pipelines, and it applies policy gates. It does not sign, build, or release artifacts. |
| Deploy | Not Offered as runtime enforcement | Assessment and validation only. Deployment-related controls are assessed where evidence can be read; controls that cannot be observed are reported as not verified. Assurance-AI is not deployment enforcement, agent registration infrastructure, runtime credential management, or a runtime guardrail layer. |
| Operate | Not Offered | Assurance-AI is not continuous production runtime protection. |
| Monitor | Not Offered as continuous runtime monitoring | Assurance-AI can assess whether monitoring controls are evidenced and can consume execution evidence from its own tests. It is not a SIEM, runtime agent monitoring, continuous tool-call surveillance, or inline anomaly detection. |
| Govern | Implemented | Control evidence, versioned framework mappings, an evidence matrix, a risk register, maturity with a verification-coverage guard, a guardrail approval and retest lifecycle, and the confirmed versus not-verified distinction. |
Capabilities
Agentic security capabilities
Each capability describes what the platform does today and where its limits are.
Agentic threat modeling
Models agent identities, privileges, trust boundaries, tools, data flows, and MCP integrations, then raises threats such as tool abuse, over-privileged agents, privilege escalation, and unauthorized function invocation.
Agent and tool abuse testing
Repeatable scenarios for tool misuse, unauthorized function invocation, excessive agency, and privilege-boundary violations, selected deterministically from a curated catalog.
MCP-style tool-call security testing
MCP-style tool-call security testing using a controlled reference fixture, comparing vulnerable and hardened authorization policies on the same agent.
Evidence-based outcome evaluation
Where action-level evidence is available, a verdict reflects what the agent did, observed through an execution trace and independent observers. Model text alone is not treated as proof of a security effect.
Control verification
Claimed and expected controls are checked against repository, pipeline, and test evidence. Each is reported as a verified control, a confirmed gap, or not verified.
Guardrail validation
A tool-policy control is proposed from evidence, approved by a person, and applied by an operator. The platform then retests with fresh evidence and records verified, failed, or not_verified.
CI/CD assurance
Pipeline security gates, dependency and lockfile analysis, workflow and container image pinning checks, supply-chain evidence, and SARIF and report output that keeps framework, version, and risk identifier together.
Evidence model
Evidence before conclusions
Missing evidence is not automatically treated as proof that a control is absent. Unknown never silently becomes secure, and it never silently becomes a finding either.
Confirmed security condition
Available evidence establishes the outcome or the missing control. A control is reported as missing only when Assurance-AI can see where it would be declared and the expected evidence is absent. Insecure conditions that are observed directly, and UNSAFE test verdicts backed by valid evidence, are also confirmed.
Not verified
Available architecture, repository, pipeline, or execution evidence is insufficient to establish whether a control is present or absent. It is an assurance gap: never a pass, never reported as implemented, and never reported as missing.
Verified control
Evidence supports that the expected control is present within the tested scope. Evidence has stated limits, and tool-name signals alone are not treated as proof that something is absent.
How this changes results
- Reports separate confirmed findings from not-verified assurance gaps. Not-verified items stay visible but are excluded from confirmed-risk totals.
- In architecture review, supplied evidence can corroborate or contradict a claimed control. Not-verified evidence earns no credit and applies no penalty.
- A failed evidence collector cannot produce a pass.
Verification coverage and maturity
- Maturity scores only controls that could be verified.
- If too few applicable controls could be verified, no overall maturity rating is published. The result is reported as Not sufficiently verified.
- A verified-scope result may still be reported. It describes only the verified subset and is not an overall maturity rating.
Framework mapping
OWASP Top 10 for Agentic Applications 2026
Assurance-AI supports version-aware mapping to the OWASP Top 10 for Agentic Applications 2026.
Why version identity matters
A risk identifier means nothing without its edition. Assurance-AI keeps the framework, the version, and the risk ID together, and never assumes the newest edition for an unversioned identifier. For example, LLM08 is a different risk in the 2023 and 2025 editions of the OWASP LLM Top 10.
How to read the matrix
Mappings come from reviewed scenario, rule, and threat metadata. They are not inferred from keywords. A mapping states that a scenario or check is relevant to a risk. It does not mean the risk is fully covered or eliminated.
| OWASP Agentic risk | Assurance-AI evidence source | Coverage |
|---|---|---|
| ASI01 Agent Goal Hijack | Adversarial scenarios: indirect prompt injection, agent cloaking, and cross-session leakage. | Scenario mapping, response-level. |
| ASI02 Tool Misuse and Exploitation | Adversarial scenarios (tool abuse, excessive agency, agent escape, SDK tool bypass); architecture threats (tool abuse, MCP tool abuse, unauthorized function invocation); repository and CI/CD rules on tool capability, allowlists, approval gaps, and MCP tool permissions. | Broadest coverage: scenarios, threat modeling, and static checks. |
| ASI03 Identity and Privilege Abuse | Architecture threats (agent escalation, over-privileged agents); repository and CI/CD rules on MCP authentication and permission validation; a small set of message-manipulation and cross-session scenarios. | Threat modeling and static checks; limited scenarios. |
| ASI04 Agentic Supply Chain Vulnerabilities | Agent supply-chain scenarios. | Scenario mapping, response-level. Pipeline supply-chain checks are reported separately and are not mapped to this risk. |
| ASI05 Unexpected Code Execution (RCE) | Repository rules for agent and MCP tools with shell or command execution capability; one agent-escape scenario. | Static detection; one scenario. |
| ASI06 Memory & Context Poisoning | Scenarios that poison retrieved context. | Limited, response-level. Not agent-memory testing. |
| ASI07 Insecure Inter-Agent Communication | Multi-agent collusion and agent-message manipulation scenarios. | Limited, response-level. Not inter-agent protocol testing. |
Transparency
Capability status
Uses the same status labels as the AI & Agentic Red Teaming page: Implemented, Reference Fixture (demonstrated on a controlled reference fixture), and Not Offered.
| Capability | Status |
|---|---|
| Architecture threat modeling for agent, multi-agent, MCP, and RAG designs | Implemented |
| Version-aware OWASP Agentic 2026 mapping (risks listed above) | Implemented |
| Agent and tool abuse scenarios, response-level evaluation | Implemented |
| Agent and tool abuse scenarios, action-level evidence | Reference Fixture |
| Evidence-based control verification (confirmed, not verified, verified) | Implemented |
| CI/CD security analysis and fail-closed gates | Implemented |
| Supply-chain evidence assessment (pinning, lockfiles, SBOM, signing, and provenance tooling) | Implemented |
| Guardrail proposal, approval, and retest lifecycle | Reference Fixture |
| MCP-style tool-call testing | Reference Fixture |
| Testing of arbitrary external MCP servers | Not Offered |
| MCP protocol conformance testing | Not Offered |
| A2A protocol attacks | Not Offered |
| Autonomous red-team agents | Not Offered |
| Continuous production agent monitoring | Not Offered |
| Automatic production guardrail changes | Not Offered |
| SIEM | Not Offered |
| Runtime enforcement, including an agent firewall | Not Offered |
Transparency
What Assurance-AI does not do
Stated plainly so a reviewer does not have to infer it.
Testing and monitoring
- It is not an autonomous red-team agent and does not run continuous prompt fuzzing.
- It does not test arbitrary production MCP servers or MCP protocol conformance.
- It does not test agent-to-agent protocols or spoofing.
- It is not a SIEM and does not provide continuous production agent monitoring.
Enforcement and claims
- It is not a runtime agent firewall and does not enforce policy in production.
- It does not change production guardrails automatically. People approve and apply controls.
- It is not evidence of OWASP certification or compliance.
- It does not replace independent review of results.
Related
Where to go next
Assured-AI Security applies Assurance-AI within professional engagements, alongside independent expert review.
AI & Agentic Red Teaming
Adversarial testing, evidence-based evaluation, guardrail retesting, and CI/CD gates.
View the pageArchitecture Review
Independent review of agent, MCP, and RAG architectures before deployment.
Learn moreAI/LLM Assessment
Assessment of an existing AI-enabled application under realistic attack conditions.
Learn more