Mapping an agentic control set into OpenCRE: link targets and two scope questions

Context

I am mapping an agent security control taxonomy into OpenCRE, covering the Agent Governance Toolkit and the agentrust-io specs. This was raised with Rob by email today; opening it here so the evidence is on the record and so others working agentic mappings (#1017) can see it rather than rediscovering it.

Following the approach in #1017: two proposals, not the whole set, and feedback on shape first.

Method

Full corpus pulled via /rest/v1/all_cres, 27 pages, 522 CREs. Cross-checked against an independent walk of Contains edges from the five roots, which returned the same 522. Every id below was verified to exist.

Finding 1: AI coverage is strong, and I am not proposing anything there

85 CREs sit across the three AI branches (663-200 Technical AI security controls, 225-553 Organizational AI security controls, 803-457 Protection against AI-Specific Threats) and their descendants. Prompt injection in particular is better covered than in our own taxonomy: 686-110, 012-625, 843-475, 106-447.

Of 30 controls in our first pass, 25 map onto existing CREs. That is a good result and it is worth stating before the gap.

Finding 2: the agentic layer has no requirements

Searching all 522 CRE names:

term	matches
agent	0
delegation	0
autonomy	0
attestation	0
provenance	0
non-repudiation	0
plugin	0
identity	1, inside an MFA recovery control

Session and authentication are well covered, but every one of those CREs is cookie-shaped or human-login-shaped. There is no representation of a non-human principal that holds its own identity, acts on its own, and passes authority to another such principal.

Two proposals

1. Agent delegation chain

• Proposed parent: a new "Agent identity" under 663-200 Technical AI security controls
• Relations: 123-124 Minimize permissions, 128-128 Strong authorization checking
• Why: 123-124 covers least privilege for one principal. Nothing covers privilege that must narrow across a chain of principals. An agent delegates to a sub-agent, scope must shrink rather than persist, and depth must be bounded. That is the defining agentic case and it has no home today.

2. Runtime attestation evidence

• Proposed parent: 663-200 Technical AI security controls
• Relations: 170-772 Cryptography, 307-507 Allow only trusted sources both build time and runtime
• Why: 307-507 and 171-222 cover build-time integrity, meaning trust that the artifact was built correctly. Nothing covers runtime evidence of what is actually executing, which is what hardware-backed attestation provides and what agent deployments increasingly need.

Useful anchors found along the way: 220-442 Model action privilege minimization is a natural parent for tool-level controls, and it was the closest existing match to anything agentic in the whole corpus.

One question

Is there a way to express where in an agent loop a control applies? We enforce at eight points (agent startup, input, pre model call, post model call, pre tool call, post tool call, output, shutdown). That reads like a placement dimension rather than a control, so it may want a tag or a relation type, or it may be out of scope. Happy either way, but it affects how several further proposals should be shaped.

Related

#1017 (AVE agentic mappings), #1015 (LLM Top 10 2026), #1016 (AISVS 1.0)

There are 17 further proposals behind these two. I would rather get the shape right on two than submit a batch that needs reworking.

No implementation file or test is named. Start by reviewing the /rest/v1/all_cres corpus and related issue #1017, then trace how OpenCRE represents controls and relations. Done means the two proposed control shapes and the agent-loop placement question have an agreed representation before further proposals are submitted.