Agent Control Standard (ACS) with NEXUS A2A Protocol - AI Agent Runtime Guardrail Framework
ACS Gets the Hard Part Right. Here’s What It Still Can’t Stop — and How NEXUS Fills the AI Agent Control Plane Gap.
If you have been tracking the agentic AI security space, you have noticed ACS.
The Agent Control Standard gets something right that most of the field has ignored: intercepting tool calls before they execute and running them through an external policy engine (the Guardian). This is not a small thing. It addresses a genuinely underappreciated attack class — “legitimate credential, illegitimate specific argument” — where an agent with valid access rights makes a call that the policy should have blocked.
An agent authorized to read files should not be able to call read_file(path=”../../etc/passwd”). An agent authorized to query a database should not be able to run DROP TABLE users. ACS Guardian catches these. OPA rules outside the agent process see actual arguments, not just capability categories, and can enforce them.
This is architecturally sound agent control plane. It is also insufficient for a complete sovereign agent deployment.
What follows is not a critique of ACS. It is a precise analysis of the gap between what ACS v0.1.0 addresses and what a production agentic system requires — and a description of the NEXUS bridge that makes the two work together.
What ACS v0.1.0 Framework Provides – Runtime Agent Governance
ACS defines a Guardian integration profile using AOS (Agent Operation Spec) JSON-RPC 2.0. The Guardian sits outside the agent process and evaluates step contexts before execution. Step types include toolCallRequest, memoryStore, knowledgeRetrieval, and message.
Per-call argument inspection is the primary value proposition. The Guardian sees the actual arguments the LLM chose to pass, not a higher-level capability grant. This closes a real gap.
ACS also introduces partial non-repudiability through the NOR (No-Operation Receipt) analog in the Guardian response. The Guardian issues a verdict; that verdict can be logged. The chain-of-custody structure is less complete than a full cryptographic receipt, but the intent is correct.
What ACS v0.1.0 Leaves Open at the Agent Control Plane
Identity. The StepContext.agent.id in AOS is a bare string. There is no cryptographic binding between the string and the actual running process. An agent can claim any ID. The Guardian evaluates policy against an identity that cannot be verified.
This matters in multi-agent systems. If Agent B receives a delegation from Agent A, the Guardian sees two string IDs. It cannot verify that Agent A is who it claims to be. It cannot verify that Agent B is operating within the scope actually granted by Agent A. The delegation relationship is asserted, not proven.
Delegation governance. ACS does not model delegation chains. There is no concept of scope attenuation across hops. An agent three levels deep in a delegation chain has, by default, whatever the application session allows — not whatever the root principal narrowed it to.
Memory governance. The memoryStore step type provides a hook for memory write interception. But ACS does not define what the Guardian should check: no drift detection specification, no provenance metadata format, no zone classification. A Guardian implementation that does nothing with memory writes is ACS-compliant.
Supply chain. ACS has no mechanism for tracking the tool surface available to a given agent at a given moment. If a new MCP server is connected between sessions, that connection is not automatically visible to the Guardian’s policy context.
These are not fatal flaws. They are design scope boundaries. ACS focused on enforcement at the point of tool execution. The layers below (identity) and above (memory, supply chain) were not in scope for v0.1.0.
NEXUS fills exactly those layers.
The NEXUS-ACS Open Source Bridge: How Agent Control Standard Works
NEXUS-A2A v0.3 ships a complete ACS bridge (NEXUSACSBridge) implementing the NEXUS-ACS Bridge Specification v0.1. The bridge translates NEXUS CAEL envelopes into AOS JSON-RPC 2.0 Guardian requests.
The key AI agent control plane architectural decision: full backward compatibility. ACS Guardians that do not implement NEXUS receive valid AOS StepContext objects. The NEXUS identity and governance context travels in the nexus: extension block, which ACS-only Guardians ignore.
from nexus_sdk.bridges import NEXUSACSBridge
bridge = NEXUSACSBridge()
# Build a Guardian request from a NEXUS CAEL tool call
request = bridge.build_tool_call_request(
cael_tool_call={
"tool_name": "read_file",
"arguments": {"path": "/data/q2-analysis.csv"},
"tool_call_id": "tc-001",
"provenance": {
"requested_by_did": "did:nexus:agent:research-agent",
"delegation_depth": 1,
},
},
reasoning="Retrieving Q2 analysis data for comparison task",
)
# request["jsonrpc"] -> "2.0"What this achieves layer by layer:
Layer L2 (Identity): The agent’s DID and SPIFFE ID travel in the nexus: block. A NEXUS-aware Guardian can verify these cryptographically. An ACS-only Guardian ignores them and evaluates against the string ID as before.
Layer L3 (Policy): ACS Guardian evaluates per-call arguments (its core strength). NEXUS OPA evaluates capability scope and AISM invariants. Together, they cover both “wrong argument for this tool” and “wrong capability scope for this agent.”
Layer L4 (Memory): NEXUS Memory Vaccine validates drift before the memoryStore step context reaches the Guardian. The Guardian receives a provenance-tagged memory write request. A NEXUS-aware Guardian can enforce drift thresholds tighter than the Vaccine’s default 0.30 cosine distance.
from nexus_sdk.memory import MemoryVaccine, MemoryZone
vaccine = MemoryVaccine("did:nexus:agent:research-agent", "Q2 analysis", use_stub_embeddings=True)
# Validate and get provenance for the Guardian
decision = vaccine.validate_write(
content="Q2 revenue: $4.2M, up 18% YoY",
zone=MemoryZone.CROSS_SESSION,
owner_did="did:nexus:person:analyst",
)
acs_ctx = vaccine.to_acs_guardian_context(
content="Q2 revenue: $4.2M, up 18% YoY",
zone=MemoryZone.CROSS_SESSION,
owner_did="did:nexus:person:analyst",
decision=decision,
)
# acs_ctx contains: zone, drift_score, embedding_hash, source_did
# Feed this to build_memory_store_request -> Guardian sees provenance
memory_request = bridge.build_memory_store_request(
content=["Q2 revenue: $4.2M, up 18% YoY"],
agent_did="did:nexus:agent:research-agent",
provenance_dict=acs_ctx,
)
The Combined Stack: Better Than Either Alone
The NEXUS-ACS integration is not additive. It is multiplicative.
ACS Guardian catches: “this agent has read_file scope, but this specific path argument is a traversal attack.”
NEXUS OPA catches: “this agent has read_file scope, but it is at delegation depth 3 and was only authorized to read within the /data/q2/ directory at depth 0.”
Neither catches both alone. Together:
- ACS covers: argument-level per-call enforcement (its core strength)
- NEXUS covers: cryptographic identity, scope monotonicity across delegation chain, memory provenance, supply chain tracking, non-repudiable NOR audit chain
An agent operating under both produces a deterministic, cryptographically verifiable record of every action: who authorized it, at what delegation depth, under what scope, with what arguments, producing what outcome. This is the forensic foundation that EU AI Act compliance, SOC 2, and enterprise incident response require.
The AISM Invariants as ACS Guardian Policy Templates
The six NEXUS AISM Invariants ship as OPA/Rego policy files (opa/nexus-aism-invariants.rego) that can be loaded into any ACS-compatible Guardian.
Each invariant produces machine-readable violation messages:
I-1 VIOLATED: agent.did absent — communication boundary is unauthenticated
I-2 VIOLATED: scope amplification at delegation depth 2 — ‘admin:delete’ not in parent grant
I-3 VIOLATED: CROSS_SESSION memory write has no embedding_hash — drift detection disabled
I-4 VIOLATED: ACT-2 agent ‘did:nexus:agent:…’ has no registered kill switch pathway
These run inside OPA. They are enforceable, not advisory. The Guardian verdict is deny if any invariant is violated.
Loading the NEXUS invariants into your ACS Guardian:
# If your Guardian uses OPA bundle loading:
cp opa/nexus-aism-invariants.rego /your-guardian-policy-dir/
# OPA picks it up automatically on restartGovernance and Steering Committee
The NEXUS-ACS Bridge Specification is a joint contribution. CSI engages the ACS workstream through structured contribution, and the NEXUS Technical Governance Committee (NEXUS-TGC) treats the ACS bridge as a first-class maintained component.
The NEXUS-TGC is currently accepting steering committee nominations (open through September 1, 2026). Organizations building ACS-based Guardian deployments who want input into bridge specification evolution are invited to nominate.
Quick Integration Checklist – Control Plane for AI Agents
- Install the SDK: pip install nexus-a2a-sdk
- Copy opa/nexus-aism-invariants.rego into your Guardian’s policy bundle
- Point agent tool calls through build_tool_call_request()
- Wrap memory writes with MemoryVaccine + to_acs_guardian_context() before sending to build_memory_store_request()
- Run nexus-score.py –v03-checks to verify your integration
Full working example: examples/acs_bridge.py in the repository.
NEXUS-A2A v0.3 | Apache 2.0 | Cyber Strategy Institute
NEXUS-ACS Bridge Specification v0.1 is a joint contribution; feedback welcome via GitHub issues.
