UUSAP
Open source · Apache-2.0 · runs in any LLM

Security agents that show their work.

Most AI security tools hand you a confident answer you can't check. USAP hands you a verdict that cites evidence you can re-fetch — and waits for a human before it changes anything.

Graded on real incidents — Log4Shell · xz · Capital One · Okta · MOVEit · Midnight Blizzard

cs-cloud-investigatorhigh

Public S3 → IMDSv1 → IAM-wildcard exposure chain.

source mcp:cloud:list_findings
Action:* on Resource:*
human_approval_required: false
the loop · signal → signed verdict
01
Signal
alert · PR · finding
02
Reason
cs-* agent classifies
03
Fetch
resolve MCP · pull evidence
04
Verdict
11-field typed JSON
gate
Evidence gate
resolvable or rejected
gate
Human approval
for anything mutating
07
Dispatch
router → physical MCP
08
Sign
hash-chained · HMAC
Alert TriageThreat HuntingIncident ResponseCloud PostureContainer ScanningSupply-Chain DefenseDetection EngineeringRed / Purple Teaming
Alert TriageThreat HuntingIncident ResponseCloud PostureContainer ScanningSupply-Chain DefenseDetection EngineeringRed / Purple Teaming

How it works

One path, from signal to signed verdict

01

Reason

A cs-* agent classifies the signal and pulls the evidence it needs over MCP — from whatever SIEM, cloud, or code host you actually connected.

02

Gate

The typed verdict passes the evidence gate; anything that mutates the world waits behind explicit human approval.

03

Execute & sign

On approval, MCP dispatches to the real tool. Every step lands in a tamper-evident, signed audit log.

Real output · not a mockup

This is what an agent actually returned.

No marketing copy on this page pretends to be product. The card below is verbatim output from a USAP skill — run it yourself and you get the same shape. Here's how to read it.

python3 cloud-infra/cloud-security-posture/scripts/cloud-security-posture_tool.py --output json
cs-cloud-investigator· cloud-security-posture
highconf 0.86

action

Escalate the public-S3 → IMDSv1 → IAM-wildcard exposure chain: hand off to cloud-workload-protection for runtime containment and identity-access-risk for the over-permissive role.

key_findings

  • public-s3-bucket — arn:aws:s3:::acme-prod-customer-exports has a public-read ACL (CIS AWS 2.1.5); holds customer PII exports
  • imdsv1-enabled — instance i-0a1b… permits IMDSv1, HttpTokens=optional (CIS 5.6); SSRF → instance-credential theft
  • iam-wildcard — role/app-runtime allows Action:* on Resource:* (CIS 1.16); lateral movement once creds are stolen
  • cloudtrail-disabled — CloudTrail off in us-west-2 (CIS 3.1); masks the exfiltration path

evidence_references[0]

source mcp:cloud:list_findings:call_csp7f21
ref   arn:aws:iam::123456789012:role/app-runtime
quote Statement[0]: Effect=Allow, Action=*, Resource=*
T1530T1552.005T1078.004T1562.008
human_approval_required: false
next → cloud-workload-protection · identity-access-risk
1

It reasoned, it didn't list

Four findings, but the verdict names the exploitable chain between them — public bucket, stealable instance creds, a wildcard role to move with, logging off to hide it. An attack path, not a scanner dump.

2

The evidence resolves

The cited source is a live MCP tool-call id with the exact policy statement it read (Action:* on Resource:*). Not "the scan showed it" — a pointer you can re-fetch.

3

Mapped to ATT&CK

T1530, T1552.005, T1078.004, T1562.008 — the chain, in the framework your detections already speak.

4

It escalated — it didn't touch anything

human_approval_required is respected; the agent hands off to containment and IAM review. The world only changes when a person says so.

Tell us where it's wrong

Ran it against your stack? I want to know what broke.

It's early and I'm the sole maintainer. Real feedback — a verdict that missed, a connector that didn't resolve, a gate that felt wrong — is what moves this forward. Two minutes helps more than a star.