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

[imran-siddique]

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.

[chaksaray]

Both proposals map closely onto something AVE already has real, published evidence for, not just conceptual agreement.

On delegation chain: AVE-2026-00048 documents exactly the failure your 123-124 gap analysis names, a sub-agent spawned with inherited permissions and no trust boundary, scope persisting instead of narrowing across the chain. That's independent confirmation this corresponds to a real, observed vulnerability class, not a theoretical gap. Happy to share the record's full fingerprint if it's useful evidence for the proposal itself.

On runtime attestation: this is close enough to an independent contributor's own project, an execution-evidence attestation predicate built specifically around the declared-versus-observed distinction you're describing, that I think you two should talk directly rather than have me relay. Pointing them at this issue.

On your lifecycle-placement question: AVE has something adjacent, not identical. Our entry_class field distinguishes where in a component's lifecycle a behavior fires, discovery-time (before any tool call), runtime (during execution), registration/config-time, or embedded directly in instruction content. Doesn't map one-to-one onto your eight hook points, but it's a real, already-tested answer to a similar underlying question, might be worth comparing shapes even if the final granularity differs.

Genuinely useful that you're doing two proposals carefully rather than seventeen at once, happy to go deeper on either.

[robvanderveer]

Thank you for this very helpful and thoughtful input, although I find the dramatic title to be a bit on the nose. This is by design.
Let's explore to see if something can be done and what.
First of all, the vision of OpenCRE and the AI Exchange is that Agentic AI matters should be integrated in security and not bolted on. That helps practitioners to extend their existing way of working instead of being overwhelmed with things that seem entirely new.

Some thoughts to iterate on:

1. agent identity as a concept is not a new control, it represents a gap in how the existing controls deal with a fundamentally more dynamic actor. By adding it as a control to the taxonomy we would effectively be confusing practitioners. We're talking about properties of identity (more scalable, more ephimeral) and authorization (more just-in time).
   123-124 Minimize permissions is just a name. It refers to standards. If those standards don't cover attenuation, then that is not something for OpenCRE to solve by adding controls. A way to solve this is to link from 123-124 to control taxonomies that describe it. Then it becomes a judgement call whether attenuation needs to become a sub control. Sub controls are there to help organize sections of standards into groups. Once we'll have multiple sections that discuss attenuation then we can create that sub category, because then it will help to organize.
   In other words: OpenCRE should be seen as an organizer of requirements, not as a list of requirements. That makes the structure data-driven.

2. 307-507 explicitly mentions runtime and therefore is the perfect fit for runtime attestation. Suggestions?

To your question: OpenCRE is a graph and therefore suggests relations between controls, but it cannot express complex relations such as where controls have a plage in the agent loop - unless you can make CREs to group controls in the loop. That seems early, but who knows. What is perhaps helpful is that if your standard gets added to OpenCRE, then the name of your control will be shown and if that includes the point - you have that organizin principle visible, without amending the OpenCRE taxonomy.

Let's continue!

[imran-siddique]

@robvanderveer That rule is the useful part, so I rebuilt against it rather than defend the first pass. OpenCRE organizes requirements that standards state, and a sub-control earns its place once several standards have sections to group there. Applied to all 30 controls, all 19 proposed CREs collapsed into links. The second pass proposes none: 30 sections, 62 links, 53 distinct CREs, all existing. Sheet coming to you by mail since I cannot attach a binary here.

Agent identity. Agreed, and it was the weakest of the five. It stated no requirement of its own. What is required is that the authorization decision has an authenticated non-human principal, which is 633-428 with a different subject.

Attenuation. Agreed on placement, linked to 123-124 and 220-442. One note for the AI Exchange side rather than here: #LEAST MODEL PRIVILEGE already says to execute actions only with the rights of the initiating user, which is attenuation one hop deep. The wording stops where an agent delegates to a sub-agent. That is a text change on the page if it is worth making, not a node in the graph.

307-507, since you asked for suggestions. It is the right link target and I have used it. What sits there today, excluding the CAPEC auto-linker, is ASVS V10.3.2, SSDF PS.2.1, CWE-353 and the Docker cheat sheet. All four are the deployer verifying artifacts it controls. Attestation is a relying party appraising evidence about a platform it does not control. PS.2.1 is closest, since it is a producer supplying verification information to an acquirer, but one section is not enough to group under your rule.

So rather than argue for a sub-control, the useful contribution is the data that would settle it. RFC 9334 (RATS Architecture, Informational, January 2023) defines attester, verifier and relying party, and is the vocabulary the rest of this area borrows. It is not ours and it is not agentic. I will prepare that mapping as a separate contribution if it is wanted. If those sections land at 307-507, the question answers itself from the data rather than from me.

Loop placement. Your suggestion works and I have used it. 14 of the 30 control names now start with the enforcement point, so the organizing principle is visible without amending the taxonomy. The other 16 have no single point and are unprefixed rather than forced.

On the linking method. CONTRIBUTING.md calls the automated method preferred because it is self-maintaining, and we control every one of these spec texts, so that is what we should use. We will put opencre.org/cre/<id> references into the control text and tell you how to read the source. That makes the spreadsheet the artifact for agreeing terminology rather than the delivery mechanism, which I think is the right division anyway, since terminology is the part that needs you and the links are the part that should not need either of us twice.

Two things from the plumbing, separate from the agentic question:

1. docs/CREmappingtemplate.xls was last saved November 2024. 428 rows, zero AI CREs, no 663-200 branch and no 803-457. Anyone mapping an AI or agentic standard with the published template maps into the pre-AI tree and re-proposes what already exists, which is part of how I got to 19. I have a blank regenerated from the live graph in the same columns and the same Contains ordering, 522 rows. Happy to open a PR if you want it, but I read the note about closing PRs against unacknowledged issues, so say the word first.

2. Four scope questions came out of the pass. Three look like description edits rather than gaps: whether 633-428 covers a non-human principal, whether 088-316 covers memory an agent writes during a run, and whether 470-731 covers a long-lived non-human session. Each of those subtrees reads human and browser shaped the whole way down. The fourth is the only place I still think something is absent, and it is a threat rather than a control: 267-786 has 182-732 direct runtime model leak, which assumes an attacker rather than the infrastructure owner.

@chaksaray thanks. I have not verified AVE-2026-00048 myself so I am not citing it as evidence, but the failure shape you describe is the one I mean and I would like to see the record. The entry_class field is interesting for a reason I did not expect: it carries lifecycle placement as data on the finding rather than on the taxonomy, which is close to where Rob lands above. Happy to be introduced to the attestation-predicate contributor.

[chaksaray]

On AVE-2026-00048: sharing it directly rather than making you take it on faith. https://api.aveproject.org/records/AVE-2026-00048. Genuinely curious whether it holds up as evidence for the delegation-chain shape once you've actually read it, not assuming it does just because the pattern sounded similar in description.

On the introduction: passing your request along to the AEE contributor directly rather than arranging anything on his behalf, that's his call to make, not mine.

[imran-siddique]

@chaksaray, thank you. I reviewed AVE-2026-00048, and it is useful for this mapping.

The record clearly describes the unsafe pattern:

• a child agent inherits the parent's permissions;
• no tool allowlist or time limit is set;
• child actions may disappear from the parent audit trail.

It also gives us useful links to ASI03, MCP03, MCP07, CWE-269, and CWE-284, plus concrete checks and fixes.

One boundary is important: this AVE record describes how to detect an unsafe delegation pattern. It is not itself runtime proof that a particular delegation happened. I suggest OpenCRE map it to the delegation risk and its controls, while keeping runtime delegation-chain evidence as the separate proof that shows who delegated what authority, to whom, for how long, and what the child did.

So my answer is yes: it supports the OpenCRE work, as the risk-and-detection side of the mapping. The signed runtime chain remains the evidence side.

And thank you for passing along the contributor introduction.

[chaksaray]

That's exactly the right boundary, and worth confirming why: AVE-2026-00048's own entry_class is content, it describes a static pattern in a skill file's instructions, what to look for, not proof that a delegation with those properties actually executed. Mapping it to the risk-and-detection side while keeping runtime evidence separate is the correct read of what the record can and can't support, not a conservative hedge.

Also worth naming: this is the same declared-versus-observed distinction that's come up twice already in this thread, self-reported confidence versus structurally-backed evidence on the AVE side, detection-pattern versus runtime-proof here. Same underlying shape, third place it's turned out to matter.

Glad the introduction landed as useful.

[astrogilda]

Imran, hello, and thank you Chandra for the introduction. I am the contributor Chandra mentioned. The predicate is in review at in-toto/attestation#570, and its conformance corpus lives at astrogilda/aee-conformance. The thread moved twice since Chandra's note, so I am answering where it landed rather than the opening post.

Your second pass is the right call. I would not reopen it. Rob's rule is the useful part. OpenCRE organizes what standards already state. A sub-control earns its place once several standards have sections to group there.

So instead of arguing for a node, I can offer a second section.

On 307-507 your reading matches mine. It is the crux. The four things linked there today are all one relation. A deployer verifies artifacts it controls. Attestation is something else: a relying party appraising evidence about a platform it does not control. Those are two different trust relations wearing one word.

RFC 9334 names the difference. It is not agentic. It belongs to neither of us.

That last point is what makes it a good anchor. So yes, prepare the mapping, and I will support it and put this predicate forward as a second section on the relying-party side. Then the data answers Rob's rule for us.

You asked what this kind of evidence has to be. Here is what it must assert before a distrusting reader can check it at all. There are four, and three of them are corrections a reviewer made to my own work.

It has to bind to an identity the reader can recompute. The statement names its subject by digest, and every carried record binds to the run that produced it. Records moved between statements then stop verifying, and without that binding the evidence is about nothing in particular.

The vantage and the method have to be declared in closed vocabularies that the verifier reads, and ours carries three: basis, method and attribution. All three are mandatory. A free-text field describing how an observation was made is only a producer assertion. A reader cannot rank it.

The verdict has to be recomputed by the reader from the carried records, and never read off a field the producer filled in. That is the difference between evidence and a claim, and it is the part most formats skip.

A refusal may name only the comparisons that actually ran. That sounds like a reporting nicety. It is not.

A reviewer read an implementation of my own specification and found the failure there, in refusals naming a comparison whose operand set was empty. That happened on a third of its runs. The message told producers to repair records the check had never read.

The sharpest case for your declared-versus-grounded distinction came from a reviewer reading my own format. My wire format does not say what kind of monitor produced a record. Two monitors earn the same evidence tier, and that tier is the strength label a consumer's policy reads. One has its signing key inside the kernel it watches, and the other sits outside the workload entirely.

Whoever provisioned the deployment knows which one they have, and a third party reading the statement cannot tell.

That is now a stated limitation in the specification. It is not a new field. A carried value naming your own stack is as forgeable as the rest of the payload, so it would only relocate the problem. The discriminating fact lives in consumer key policy. A third-party reader lacks exactly that.

Here is the test I would offer. Chandra has now named this distinction three times. A value is grounded when the reader can recompute it from bytes the reader already holds. It is also grounded when signed by a key whose custody the reader's own policy names. Everything else is declared, however carefully it is worded. A control that accepts a declared value has bought a promise.

Chandra, you drew the boundary with AVE-2026-00048 correctly. I would add one mechanism to it. A detection pattern and a runtime proof have to be tested differently. A corpus made only of refusals has a trivial passer.

A verifier that refuses everything scores full marks. So every reject vector is paired with a conformant twin that has to be accepted, and a gate confirms that each one forces its condition. Mere presence never establishes that.

The corpus holds 260 vectors today. 61 are accepts, 197 are rejects, and 2 are indeterminate.

On loop placement, three of us reached the same shape. We came at it from different directions. Rob's answer was to carry the enforcement point in the control name instead of in the graph. Chandra's entry_class carries it as data on the finding. Mine carries it as data on the observation record. Placement is a property of the evidence and not a level of the taxonomy, which I think is the answer and not a workaround.

Happy to go deeper on any of it, and glad to have been introduced.

Sankalp.