You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
AgBOM components and supply-chain lookups: how should a Guardian get a package identity?
#494
We run a pre-install verdict service for packages and MCP servers (DugganUSA), and we looked at whether it could act as a verdict source for an ACS Guardian on agbom/snapshot and agbom/changed. This is a question, not a proposal.
What we read (v0.1.4: Inspect and the CycloneDX mapping). An mcp_server component has id, name, version, endpoint and tools[]. A tool has id, name, version, provider and capability. Neither carries a package coordinate such as a purl, and the CycloneDX mapping serializes mcp_server as a service. A skill carries definition.digest; the others carry no digest.
What we measured. Three of three live lookups by name came back unresolved, because our service resolves by registry identity or package, not by a bare name or an endpoint. A Guardian using us as a source would defer every such component. That is fail-closed, which is what we want, but it is not useful.
What we found in the reference implementation. We read the source on the integration branch on 2026-11-03; we did not run it. reference-implementations/agt/mapping.yaml translates six hooks: toolCallRequest, toolCallResult, sessionStart, sessionEnd, userMessage and agentResponse. We found no agbom/*, skill or protocols/MCP/* mapping. As far as we can tell, the question of how a Guardian learns a component's identity has not been exercised against a Guardian yet.
The question. Is there an intended way for a Guardian to get a component's package identity? We see three options: (a) an optional field on the component, (b) an acs:-prefixed property convention, or (c) a profile. Under Principle 3 in SPEC_REVIEW_PRINCIPLES, we cannot tell whether this is "lost otherwise". We do not know how a stdio MCP server's package identity, for example an npx package and version, appears in an AgBOM today. We are not proposing any verdict content on the wire; that is vendor territory.
We may be missing something, and we would rather ask than file a bug. If there is an answer, we are happy to test it against our service and report exactly what happens.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
We run a pre-install verdict service for packages and MCP servers (DugganUSA), and we looked at whether it could act as a verdict source for an ACS Guardian on
agbom/snapshotandagbom/changed. This is a question, not a proposal.What we read (v0.1.4: Inspect and the CycloneDX mapping). An
mcp_servercomponent has id, name, version, endpoint and tools[]. Atoolhas id, name, version, provider and capability. Neither carries a package coordinate such as a purl, and the CycloneDX mapping serializesmcp_serveras aservice. Askillcarriesdefinition.digest; the others carry no digest.What we measured. Three of three live lookups by name came back unresolved, because our service resolves by registry identity or package, not by a bare name or an endpoint. A Guardian using us as a source would defer every such component. That is fail-closed, which is what we want, but it is not useful.
What we found in the reference implementation. We read the source on the
integrationbranch on 2026-11-03; we did not run it.reference-implementations/agt/mapping.yamltranslates six hooks: toolCallRequest, toolCallResult, sessionStart, sessionEnd, userMessage and agentResponse. We found noagbom/*, skill orprotocols/MCP/*mapping. As far as we can tell, the question of how a Guardian learns a component's identity has not been exercised against a Guardian yet.The question. Is there an intended way for a Guardian to get a component's package identity? We see three options: (a) an optional field on the component, (b) an
acs:-prefixed property convention, or (c) a profile. Under Principle 3 in SPEC_REVIEW_PRINCIPLES, we cannot tell whether this is "lost otherwise". We do not know how a stdio MCP server's package identity, for example an npx package and version, appears in an AgBOM today. We are not proposing any verdict content on the wire; that is vendor territory.We may be missing something, and we would rather ask than file a bug. If there is an answer, we are happy to test it against our service and report exactly what happens.
All reactions