spec: add agent-threat-scan predicate type

[eeee2345]

This PR adds a new vetted predicate type, agent-threat-scan, that records the result of scanning an AI agent artifact (such as a Model Context Protocol server, a Claude Code skill, or a similar agent configuration manifest) against a named detection ruleset for agent-specific threats including prompt injection, tool poisoning, MCP request forgery, and skill compromise. Existing predicates do not capture this shape: vulns is oriented around CVE scanners on conventional packages, test-result is generic, and svr records that policies passed without enumerating which rules matched on a fail.

The predicate is ruleset-agnostic. Any detection ruleset that issues stable rule identifiers and a citable version may be referenced through the ruleset.uri and ruleset.version fields. One concrete example of such a ruleset is Agent Threat Rules (ATR), an open detection standard for AI agent threats licensed Apache-2.0, available at https://github.com/Agent-Threat-Rule/agent-threat-rules. ATR is currently shipped in production at Cisco AI Defense and Microsoft agent-governance-toolkit. The predicate is not coupled to ATR; the same shape applies to any other ruleset.

The schema follows the in-toto predicate conventions (lowerCamelCase fields, RFC 3339 timestamp on scannedAt, ResourceURI for scanner.uri and ruleset.uri). The Example block parses as valid JSON. New file is spec/predicates/agent-threat-scan.md, registered through spec/predicates/README.md.

Predicate URI is https://in-toto.io/attestation/agent-threat-scan/v0.1. If accepted I will follow the documented step 4 and submit the in-toto.io URL redirect addition. Happy to revise field names, severity enum, or threat-class taxonomy based on maintainer feedback. I have read the New Predicate Guidelines and the existing predicates including svr, vulns, and test-result.

[eeee2345]

Friendly ping on this one — it's been a few weeks since the last activity and I wanted to check whether anything's blocking on my end. Happy to rebase, split it into something smaller, or adjust the scope to match your conventions.

For context, Agent Threat Rules has seen meaningful ecosystem uptake since this PR opened — it was recently merged into Microsoft PyRIT, Tencent AI-Infra-Guard, and the Google ADK docs, among others — so I'd love to get this landed if it's a fit. No rush at all; just flagging that it's ready whenever you have a moment. Thanks for maintaining this!

[eeee2345]

@SantiagoTorres @adityasaky — flagging this in case it slipped by; tagging you as spec/predicates maintainers, please redirect if predicate review sits elsewhere.

It proposes an agent-threat-scan predicate type — an attestation that a given artifact was scanned for agent/LLM/MCP threats and what the result was. It follows the existing predicate conventions; no changes to the core spec.

If a predicate of this kind is not something in-toto wants to host, that is a fine answer and I would rather know than leave it open. If it needs reshaping to fit the predicate model, tell me where and I will revise.

[eeee2345]

@adityasaky @puerco — open since May with no review. Asking for a decision rather than bumping it again.

It adds an agent-threat-scan predicate type to the spec: two files, CI green, no conflicts.

The case for it in one line: attestations about AI-agent artefacts (skills, MCP server manifests, tool definitions) currently have nowhere to record what a security scan of that artefact found, and the existing predicate types do not fit the shape.

If a predicate for agent-security scan results is out of scope for in-toto, or belongs somewhere other than this repo, a clear no is more useful to me than an open PR and I will close it. What I would rather avoid is it sitting here indefinitely.