From APIs to System Agents: Intent-Driven Integration with Mutual Zero-Trust

1. Introduction

APIs have dominated system integration for decades, and their strength — explicit, stable contracts — is also their cost driver: every consumer implements provider-specific endpoints, parameters, authentication flows, schemas, error codes, and versioning rules. Studies document growth in web API size [10], damage from breaking changes to consumers [11], recurring authorization and consumption failures [9], and the apparatus of gateways, tokens, and sidecars accumulated to keep API-mediated communication safe [17,18,19,20].

Even a technically secure API leaves a fundamental imbalance untouched: the consumer must know how the provider works — endpoint, version, parameters, recovery behavior — while the provider owes little beyond documentation, so every provider change forces every consumer to change, a coupling that is at once maintenance tax and attack surface.

In SA2A (System Agent-to-Agent), each system exposes one System Agent at its boundary instead of an expanding set of operation-specific endpoints. External parties express desired outcomes as signed, intent-level envelopes; the receiving agent verifies the requester cryptographically, evaluates deterministic local policy, requests missing information when necessary, executes through internal mechanisms, and returns a signed, field-filtered response. Internal services keep using APIs, databases, or queues unchanged: SA2A replaces not APIs inside systems but their exposure between systems.

The threat model dictates the defining principle: a peer agent runs inside another organization’s infrastructure and may be compromised or malicious, so pairing establishes identity, never trust. SA2A therefore applies mutual zero-trust [6,7]: every message, request or response, passes an entry gate at the receiving agent. A response is data to be verified, never commands to execute — blocking a compromised provider from instructing a requester to damage its own system.

Four research questions guide the evaluation. RQ1: Can intent-driven integration be implemented with commodity components while preserving functional correctness? RQ2: Does it withstand a designed adversary battery, including response-direction attacks? RQ3: What integration-effort and evolution advantage is measurable against a strong REST baseline? RQ4: What performance and message-size cost does it pay, and where does it come from?

Contributions. (i) An architecture and protocol (SA2A v0.1, Amendment AM-01) with symmetric verification gates, frozen reason codes, negotiation, human-approval gating, and tamper-evident audit. (ii) A three-agent prototype — restricted requester (A), privileged requester (C), data owner (B) — with an eighteen-attack adversary harness (X) covering both directions, validated by 473 automated tests and a twelve-scenario end-to-end suite. (iii) A live comparison against a deliberately strong REST baseline over six metrics (M1–M6), including the two SA2A loses: per-call latency (+15.6 ms, +313%) and client library size (824 vs. 179 logical lines of code). (iv) Two ablations attributing defensive value to individual mechanisms rather than the whole pipeline: the provider’s six verification layers and the response gate’s six checks, the first ablation of mutual zero-trust itself. (v) A latency decomposition locating the overhead: hash-chained audit and nonce writes 84.6% of a call, all cryptography 1.6%, policy evaluation 0.1%, redirecting optimization toward the mechanism actually responsible.

2. Related Work

2.1. API-Centric Integration and Its Costs

Web API evolution studies report persistent growth in API size and client burden [10]; semantic-versioning analysis of a major package ecosystem reports downstream breakage from incompatible releases [11]. OWASP’s API Security Top 10 ranks broken object-level authorization, broken authentication, and unrestricted resource consumption among the most prevalent risks [9]. Microservice-security reviews describe an expanding defensive stack — gateways, service meshes, token services, sidecars — each needing configuration, monitoring, and patching [17,18], applied inconsistently in practice [19], with authentication and authorization the most error-prone concerns [20]. SA2A keeps these lessons — least privilege, explicit identity, defense in depth — while changing the unit of integration from endpoint to intent.

2.2. Zero Trust as an Integration Principle

NIST SP 800-207 gives the reference formulation of zero trust — no implicit trust from network location, an access decision per resource request [22] — and surveys systematize its principles and deployment models [6]; migration frameworks stress continuous verification as a discipline, not a product [7], and orchestration work highlights the operational cost of verifying consistently at scale [8]. SA2A extends the discipline where these works imply but do not develop it: verification covers responses returning to the requester, not only requests arriving at a resource — the requester being itself a system with a database and a policy domain against which a compromised provider is a threat actor.

The response direction is not entirely unguarded in existing practice, and the novelty claim must be scoped accordingly. HTTP Message Signatures [21] and mutual TLS both let a requester authenticate a response’s origin, and both are mature, standardized mechanisms. Neither, however, constrains what a response may contain, binds it to an outstanding request chain, detects its replay, or forbids its content from reaching an execution path. The SA2A response gate adds correlation, replay, field-scope, and data-not-commands checks on top of origin authentication, applies them to every message with the same normative force as the provider-side gate, and returns the same frozen reason codes when they fail. That combination — not response signing as such — is what we claim is unformalized in existing integration protocols.

2.3. Agent Interoperability Protocols

Anthropic’s Model Context Protocol (MCP) standardizes how a model connects to tools and data sources [2]; a landscape analysis catalogues its adoption and security threats [3]; Google’s Agent2Agent (A2A) addresses task exchange between autonomous agents [1]. (SA2A is independent of A2A and does not extend it; the name denotes System Agent-to-Agent integration.) Surveys of LLM-based agents map the planning, memory, and tool-use design space [4,5]. SA2A is complementary in three respects: semantics are deterministic, intents resolving to registered capabilities evaluated by a rule-based policy engine rather than model inference; trust is organizational rather than sessional, with pairing, frozen reason codes, human-approval gating, and hash-chained audit as protocol-level concerns; and verification is mutual in both directions.

Table 1. Positioning against representative integration approaches (qualitative).

Property	REST/OpenAPI	MCP	A2A	SA2A (this work)
Unit of integration	Endpoint + schema	Tool/resource descriptor	Task + artifact	Signed intent envelope
Contract style	Static documentation	Server-advertised tools	Agent cards	Dynamic capability discovery
Verification direction	Client → server	Host → server	Peer tasks	Mutual, per message, both directions
Deterministic policy gate	Deployment choice	No	No	Yes (protocol-level)
Negotiation of missing data	No	No	Partial (task states)	Yes (resumable, same correlation id)
Human-approval gating	No	No	No	Yes (execute-once)
Tamper-evident audit	Deployment choice	No	No	Yes (hash-chained, both sides)
Replay protection	Deployment choice	No	No	Yes (nonce + expiry, requests and responses)

Source note. MCP and A2A rows are read from the respective public specifications [1,2,3] as of the versions cited. “Deployment choice” denotes a property the architecture neither provides nor precludes: a gateway or operator convention may supply it, but it is not part of the protocol contract, so a consumer cannot rely on it without out-of-band knowledge.

Table 1. Positioning against representative integration approaches (qualitative).

Property	REST/OpenAPI	MCP	A2A	SA2A (this work)
Unit of integration	Endpoint + schema	Tool/resource descriptor	Task + artifact	Signed intent envelope
Contract style	Static documentation	Server-advertised tools	Agent cards	Dynamic capability discovery
Verification direction	Client → server	Host → server	Peer tasks	Mutual, per message, both directions
Deterministic policy gate	Deployment choice	No	No	Yes (protocol-level)
Negotiation of missing data	No	No	Partial (task states)	Yes (resumable, same correlation id)
Human-approval gating	No	No	No	Yes (execute-once)
Tamper-evident audit	Deployment choice	No	No	Yes (hash-chained, both sides)
Replay protection	Deployment choice	No	No	Yes (nonce + expiry, requests and responses)

Source note. MCP and A2A rows are read from the respective public specifications [1,2,3] as of the versions cited. “Deployment choice” denotes a property the architecture neither provides nor precludes: a gateway or operator convention may supply it, but it is not part of the protocol contract, so a consumer cannot rely on it without out-of-band knowledge.

2.4. Signatures, Audit, and Policy Enforcement

SA2A signs every envelope with Ed25519 (EdDSA over Curve25519, RFC 8032 [23]); implementation research confirms its efficiency and side-channel robustness on constrained platforms, suiting it to high-frequency message authentication [12]. Verification presupposes byte-exact serialization, for which the JSON Canonicalization Scheme defines the envelope’s discipline — code-point sorted keys, UTF-8, compact separators [24]. Tamper-evident logging follows Schneier and Kelsey’s hash-chaining discipline for forward-secure audit logs on untrusted machines [25]; reviews of blockchain-adjacent auditing confirm momentum behind append-only, verifiable audit structures [13]. Policy enforcement is deterministic and profile-based, matching attribute-based access control models that derive decisions from subject attributes and resource sensitivity rather than endpoint identity [16]. The context is public-sector and cross-organizational integration: the World Bank’s GovTech Maturity Index identifies interoperability frameworks as a central enabler of government data exchange [14], and UNDP’s assessment of Iraq identifies interoperable government systems and cybersecurity capability as continuing needs [15].

3. The SA2A Architecture

3.1. Design Principles

Five principles govern the design. (P1) Intent over endpoint: parties state outcomes; the receiver alone decides internally how they are produced. (P2) One channel: cross-system semantics travel as signed envelopes over one operational channel; no business endpoints are exposed. (P3) Determinism: a rule engine over versioned registries and permission profiles produces replayable, explainable, auditable decisions. (P4) Mutual zero-trust: every message passes an entry gate at its receiver, in both directions, every time. (P5) Fail closed: every rejection carries a frozen reason code, and any verification failure terminates processing before execution.

3.2. System Model and Agent Anatomy

Each system runs one System Agent beside its internal services (Figure 1). The prototype runs three: Agent A (restricted requester, 127.0.0.1:8001, trust by pairing handshake), Agent C (privileged requester, 127.0.0.1:8003, trust via a pinned copy of the provider’s public key plus pairing), and Agent B (data owner, 127.0.0.1:8002) holding a SQLite database. A read-only dashboard (127.0.0.1:8004) renders per-request timelines from the audit chains, and an adversary client (X) runs the attack battery without a server. A shared library supplies one module per agent responsibility: identity and Ed25519 keys, pairing, envelope handling, policy, capability registry, negotiation, execution, human approval, synchronization, and audit.

3.3. The Signed Envelope

All protocol semantics live in one envelope with thirteen required top-level fields (Table 2). Seventeen frozen message types cover operations, discovery, registry updates, pairing, negotiation, approval, and errors; no extension point exists. Canonicalization is deterministic — Unicode code-point sorted keys, UTF-8, compact separators [24] — so any byte-level tampering invalidates the signature.

Twenty frozen reason codes in v0.1+AM-01 — among them PAIRING_REQUIRED, INVALID_SIGNATURE, REPLAY_DETECTED, MESSAGE_EXPIRED, RESPONSE_POLICY_VIOLATION, CAPABILITY_NOT_AUTHORIZED, HUMAN_APPROVAL_REQUIRED, and DATABASE_TRANSACTION_FAILED — make failure semantics part of the contract rather than an implementation detail.

3.4. Pairing and Capability Discovery

Before operational traffic, agents pair through a three-step handshake: a pair_request carrying the initiator’s identity, public key, and proposed capability scope; a pair_challenge carrying a random challenge; and a pair_response signing it, proving key possession. The responder verifies the proof and registers the peer; until an operator activates the pairing, every operational request fails closed with PAIRING_REQUIRED. Pairing establishes identity and keys, explicitly not trust.

Signed discovery replaces static API documentation. A capability_discovery_request returns the requester-specific registry view — capability identifiers, required and optional parameters, allowed fields, required actions — filtered by that requester’s permission profile and cached with its version and the response signature. Signed capability_update and capability_deprecation pushes reach only agents whose profiles grant the changed capability; an agent not granted it rejects the delivery with CAPABILITY_NOT_AUTHORIZED. Removed fields mark cached definitions stale rather than silently failing; deprecated capabilities yield signed replacement suggestions.

3.5. The Provider Pipeline and Its Five Outcomes

Agent B processes every envelope through the fixed pipeline of Figure 1, and every path terminates in exactly one of five outcomes. Allow dispatches immediately; allow with field filtering minimizes the result to the fields the requester’s profile authorizes, applying minimization per requester on every call rather than compiling it into a per-endpoint data transfer object. Execution is transactional: a mid-write failure rolls the database back and returns DATABASE_TRANSACTION_FAILED.

Require more information opens a negotiation round rather than failing: a signed more_information_required response names exactly the missing parameters and any allowed alternatives, and the requester collects them from its operator and resumes the same chain under the same correlation_id, merging previously supplied parameters with new ones — provider-guided completion replacing client-side validation against documented schemas. Section 5 measures the cost of this full round trip.

Require human approval covers operations policy classifies as sensitive: execution is suspended, a pending-approval record created, and a human reviewer, authenticated with a reviewer token on a loopback-only administrative surface unreachable from peer agents, approves or rejects, releasing exactly one execution; outside approval manipulation is rejected with POLICY_DENIED. Deny or deprecate returns a signed error carrying a frozen reason code.

3.6. Mutual Zero-Trust: The Response Gate (AM-01)

Because the provider is a potential threat actor, the requester gates the response direction symmetrically: every signed response passes six checks before its payload is trusted. R1 identity — expected provider as sender, this agent as receiver, else UNKNOWN_AGENT; R2 expiry — a 60 s clock-skew tolerance in the future direction, else MESSAGE_EXPIRED; R3 — Ed25519 signature verification against the paired peer key, else INVALID_SIGNATURE, and because that key comes from resolving the pairing, a missing or inactive pairing surfaces here as PAIRING_REQUIRED; R4 correlation — the correlation_id must name an outstanding request chain originated by this agent; R5 response replay — each accepted response message_id enters the nonce store exactly as for requests, and repetition yields REPLAY_DETECTED; and R6 response payload policy — the payload status must belong to the frozen status vocabulary and the fields inside result must be a subset of those the originating request asked for, else RESPONSE_POLICY_VIOLATION. A seventh property, the data-not-commands rule, is structural rather than executed: response content never reaches a local execution path.

The order is operational rather than normative. Expiry and skew are evaluated on attacker-supplied, unauthenticated fields and therefore carry no authenticity weight; they run first only so signature verification is not spent on plainly stale envelopes. The nonce, conversely, is recorded only after every other check has passed, so a rejected envelope never consumes a replay slot. Ablation in Section 5 measures each check’s independent contribution and the gate’s cost on the honest path.

The data-not-commands property is claimed only as far as it was established. In the prototype no code path connects response content to the execution engine; the property was verified by inspection and exercised dynamically by attack X16, which delivers a correctly signed response carrying an instruction-style directive and asserts zero side effects. The protocol requires the property and the prototype demonstrates it dynamically but does not establish it mechanically; a static reachability pass enforcing the rule at build time is future work.

Two defects in this gate were found and repaired during the artifact review for this revision, both exploitable by exactly the actor the amendment exists to constrain. First, R6’s subset check decided “structure” from “field” by inspecting the value type, so any leaked field whose value was wrapped in a container was walked as structure and never checked: {“national_id”: [“000-11-2222”]} passed cleanly. It now tests every key against the requested set regardless of value shape, recursing only into a small frozen structural vocabulary (matches, items, records, results, entries, rows), and adversary cases X15b and X15c cover the wrapped-leak variants. Second, one requester’s asynchronous push path routed an inbound operation_response straight to classification, so R4, R5, and R6 never ran there; pushed responses now pass through the same gate, and an unsolicited response naming no outstanding chain is rejected before classification. Until that fix the claim that every message passes an entry gate in both directions every time was false on one path; a compromised provider defeats a gate with one line of code on the wrong side of a dispatch table — the threat the amendment was written to address.

One scoping caveat remains. Agent C obtains the provider’s public key from a pinned copy rather than by resolving a pairing store, so its R3 verifies against a key that pairing revocation does not reach; revoking the pairing stops Agent C’s outbound requests at the provider but does not by itself invalidate the key its response gate trusts. Agent A resolves the peer key through the pairing store and does not have this gap.

3.7. Tamper-Evident Audit and Threat Model

Both sides of every exchange append events — requests, decisions, executions, violations, synchronizations — to a local hash-chained, append-only audit database in the discipline of verifiable logging [13,25]. Verification runs offline: modifying a single stored row breaks the chain and is detected as AUDIT_TAMPER_DETECTED.

The threat model admits two actor classes: an external adversary with network access but no pairing, and a compromised peer holding valid credentials for some purposes but abusing others, including the response direction. Eighteen designed attacks exercise both: X1–X12 target the provider pipeline (impersonation, tampering, replay, expiry manipulation, capability and field probing, injection-shaped parameters, privilege escalation, endpoint probing, approval manipulation, audit tampering); X13–X16 target the requester’s response handling (forged response signature, replayed response, over-broad response, instruction payload), joined by the container-wrapped over-disclosure variants X15b and X15c added with the subset-check repair of Section 3.6. The results section lists each attack, the gate defeating it, and its measured outcome.

4. Evaluation Methodology

4.1. Prototype and Test Base

The prototype comprises the three agents, the adversary client, and the dashboard on the shared library of Section 3.2. The test base is 473 automated tests — 320 unit, 122 integration, 19 security, 12 end-to-end spanning the authorized, unauthorized, negotiated, evolutionary, and adversarial paths — plus a passing ten-step guided demonstration. The count is pytest tests/’s collection total and measures the suite’s size, not its adequacy: the fully offline environment ships neither coverage nor mutation tooling, so we cannot say what fraction of the implementation the tests exercise or how many would survive a mutated build.

4.2. The REST Baseline and Fairness

Comparison targets matter more than comparison winners. The REST baseline (127.0.0.1:8005, plus a breaking /api/v2 instance on :8006) implements the standard toolkit, not a caricature: per-role DTO field minimization, API-key authentication, sliding-window rate limiting, API versioning, typed client errors. Both architectures serve byte-identical seed data from the same seed module through their real client libraries on symmetric one-hop paths, latency iterations interleaved so load drift hits both equally. The v2 instance runs unmodified baseline server code, differing only in configuration — a version flag, a port, a database path — so no code path exists for the experiment alone. Every boot wipes the agents’ data directories, regenerates all keypairs, and reseeds the provider database; figures are verbatim from the generated result files, and latency overhead is reported as measured, without normalization.

4.3. Statistical Treatment

Each mean carries a seeded percentile bootstrap 95% interval (seed 20260803, 10,000 resamples), computed with the Python standard library alone. For serial correlation, each series reports its lag-1 autocorrelation, an effective sample size n(1−ρ)/(1+ρ) beside its nominal n, and a moving-block bootstrap interval (block length 5) where the correlation matters, a wider block interval marking the plain one as optimistic. The REST-versus-SA2A comparison is paired by iteration index, and every timed series reports a drift statistic — second-half minus first-half mean — as a warmup-sufficiency check.

That check changed the headline number. The published +24.4 ms (+469%) one-hop overhead followed only three warmups, both series still drifting: between run halves REST slowed +1.17 ms and SA2A +5.65 ms — 22.5% and 19.1% of their means — so much of it was within-run warming. After twenty warmups both series are flat (REST −0.125 ms, SA2A −0.533 ms) and the paired overhead is +15.6 ms (95% CI 15.0–16.1), or +313%. Since warmups and timed iterations share the 60-requests-per-60-second budget both systems enforce, the harness now drains a full rate window after the warmups, processes and connections staying warm. Section 5 uses the corrected figure; the superseded one is kept here so the change traces to a stated defect, not a re-run.

4.4. Experiment 1: Functional and Security Validation

Experiment 1 runs 50 live iterations against freshly booted agents (177.8 s total; Windows 11, CPython 3.13.3, 20 CPUs), each covering authorized reads by A, denied-field filtering, unauthorized updates by A, and replay, tamper, and expiry probes. Two series paced inside production rate limits — thirty privileged updates by C at 3.1 s intervals, thirty negotiation round trips at 2.1 s — yield warm-process, cold-connection figures, not steady-state throughput. Human-approval enforcement, capability synchronization with authorized-only delivery, and transaction rollback under a fail-after-write injection on a co-located engine run once per run, as does the eighteen-attack battery (X1–X16 plus X15b and X15c) against a freshly booted sandbox; no attack runs 50 times. Repeating a deterministic path bounds flakiness and timing races, not error rate; we claim no statistical power over attack outcomes. Hypothesis H3 predicts an attack success rate of 0.0.

4.5. Experiment 2: Comparative Metrics

Experiment 2 measures six metrics. M1 counts exposed surface as (path, method) pairs from each server’s live OpenAPI document, excluding infrastructure endpoints on both sides. M2 counts integration effort — the invocable surface an integrator calls, and the marginal cost per added capability — in logical lines of code (docstring ranges excluded via abstract syntax tree), identically on both clients. M3 compares response bytes for the same logical query as the restricted requester. M4 measures wall-clock latency with time.perf_counter() over 50 interleaved iterations after 20 warmups, under Section 4.3’s treatment. M5 counts manual steps to add a capability and runs an unmodified v1 client against the breaking /api/v2. M6 probes security with two live attacks: replay of a captured valid request and reuse of a valid credential by a foreign holder.

4.6. Adversary Methodology and Harness

The adversary toolkit imports only the protocol’s public building blocks — envelope model, canonicalization, signing, audit verification — never another agent’s code: the adversary knows the protocol, not the implementation. X1–X9 hit Agent B over live HTTP (httpx), signed with the real Ed25519 primitives by a keypair registered nowhere, each varying exactly one envelope property: sender identity (X1, X2), a post-signature payload byte (X3), resubmission of a captured envelope (X4), timestamps in both directions (X5), undocumented-intent capability and field probing (X6, X7), injection-shaped parameters (X8), privilege-escalation-shaped writes (X9). Each structured result’s succeeded flag is true when the defense failed; attacks never assert their own rejection — the frozen reason code returned by the live system is the evidence.

Three attacks leave the request path: X10 probes REST-style business routes (POST /reserve, GET /inventory) the architecture deliberately does not expose; X11 forges human-approval administrative calls lacking the loopback origin and reviewer token; X12 edits one audit-database row directly with sqlite3, then runs the offline chain-verification routine to see whether hash chaining detects it.

For the response direction, Agent A’s production client code, genuine and fully paired, connects in process to a malicious fake Agent B behind an httpx.MockTransport, which signs with the wrong key (X13), replays a previously accepted response message identifier (X14), returns fields beyond those requested (X15), and embeds an instruction-style payload while a victim-file probe records any local side effect (X16). X15b and X15c, new in this revision, wrap the same leaked field in a list and in a dictionary, testing whether the requested-field subset check inspects every returned key or only scalar-valued ones.

4.7. Two Ablation Designs

The first ablation attributes defensive value to Agent B’s request-side layers — L1 sender-known, L2 signature, L3 expiry and clock skew, L4 nonce and replay, L5 pairing gate, L6 policy with field filtering — each disableable by configuration, every skip logged as a visible audit warning. Twelve configurations run in fresh sandboxes — the full pipeline, six single-layer removals, five compound removals (no cryptography, no identity binding, policy-only, identity-only, fully open as a lower bound) — each measured on latency, the attack battery plus unauthorized-update and denied-field probes, guidance quality (parameter-named clarification for a missing-parameter request), and data access (fields and bytes against the authorized profile). The timing design was rebuilt: the first run measured each configuration once, in fixed order, full pipeline first, after only three warmups, so every ablated configuration measured slower than the full pipeline — a positional artifact, not a layer cost. Now three rounds run with order randomized from a recorded seed, twenty warmups per configuration, and raw per-sample arrays persisted; deltas against the full pipeline carry bootstrap intervals, and one spanning zero is reported as unresolvable at this rig’s noise floor, not as a measured cost.

The same run disclosed an instrumentation defect. The harness detected attack execution by a reason code in the response, but every successful SA2A response carries one — ALLOWED, FIELD_FILTERING_APPLIED, or the ablation’s own ABLATION_POLICY_DISABLED — so the detector could never fire, and configurations that executed the attack and returned the full unfiltered record were recorded as not having got through. Execution is now decided from the frozen payload status and every affected result regenerated; the defect surfaced only in re-deriving each published number from the raw per-attack records.

The second axis ablates the response gate itself, never previously ablated though it carries the paper’s headline claim: thirteen configurations by twelve attacks — 156 cells — run in process against six checks, R1 identity, R2 expiry and skew, R3 signature with peer-key lookup, R4 correlation chain, R5 response replay, R6 payload policy. The shipped battery exercises only R3, R5, and R6, so six probes G1–G6 — defined in the ablation harness, not added to the adversary toolkit — give R1, R2, and R4 a fair test; without them those three would score redundant purely for want of an attack. G1 impersonates a third agent while signing correctly with the provider’s own paired key; G2 addresses a correctly signed response to a third agent; G3 and G4 re-deliver responses expired thirty minutes earlier and timestamped ten minutes ahead, both beyond the 60 s skew tolerance; G5 returns a correctly signed answer from an unrelated correlation chain, a different person’s record; G6 returns a status outside the frozen vocabulary that the downstream dispatcher would treat as success. Classification is by observed effect, never reason-code string: admitted requires the malicious property to materialise — a false or stale answer consumed, or fields disclosed — and non-canonical rejections count separately as degraded diagnosis. A mirror control with nothing disabled must match the production gate verdict-for-verdict — no result is an artifact of the ablation copy — and an honest-response control confirms every configuration still accepts a legitimate answer, so rejecting everything cannot score as maximally secure.

4.8. Latency Decomposition

The decomposition has three layers. Layer 1 microbenchmarks each primitive in isolation, timed in batches, against real on-disk SQLite files on the same volume as the agents’ data directories, durable-commit cost being the point. Layer 2 establishes per-request execution counts, read from the code with their call sites and confirmed against the audit and nonce rows the live agents wrote during the timed loop. Layer 3 times a ladder of increasingly complete live paths — a health GET as the transport and ASGI floor, a POST of an envelope-sized body rejected at parse, a POST running the full provider pipeline without response verification, and the complete client call the paper reports — order rotated per iteration so no fixed opening rung absorbs the wake-up cost. Primitives whose cost is contained inside another are measured but excluded from the attribution; the residual — measured total minus attributed components — is reported with its sign and an uncertainty band from pricing each attributed primitive at the edge of its interval, and is never redistributed.

4.9. Evolution Probe

The evolution probe supplies the SA2A half of M5’s breaking-change question, which the comparison harness answered only for REST. The REST change renames a wire-contract field; SA2A has no per-operation wire contract, so the equivalent change is made where SA2A keeps its contract, the capability registry: a field is removed from a capability definition and from the requester’s permission profile, the old definition replaced rather than supplemented, and the provider restarted on the broken registry with unmodified server code and only configuration data changed — the fairness rule the REST v2 instance follows. Client code is never edited. Outcomes are survived, loud, or silent: loud means the call failed with a structured, signed reason code the caller can detect and act on; silent means reported success with wrong data — the dangerous REST failure mode — counted only when the caller actually asked for the withdrawn field and was told the call succeeded without it.

5. Results

5.1. Experiment 1: Functional and Security Outcomes

Experiment 1 passed overall: all 80 authorized requests succeeded, all 100 unauthorized were rejected (100.0% each); field filtering, human-approval enforcement, capability synchronization, stale-definition handling, tamper rejection, replay prevention, and transaction rollback each scored 100%; no attack succeeded (Table 3), supporting H3. Once-per-run checks passed: the privileged update batch, negotiation round trips, approval (pending, approved, executed exactly once), zero-manual-step capability synchronization, and rollback (fail-after-write injection: DATABASE_TRANSACTION_FAILED, database unchanged, dispatch healthy).

Attack X16 was a syntactically valid, correctly signed provider response carrying {“instruction”: “delete your data”}. With no fields requested, the subset policy did not apply; the requester accepted it and did nothing—no victim-file write, no database change, no execution call. The guarantee is structural, not pattern-based: acceptance as data is not acceptance as command because no code path connects response content to the execution engine—the defense required no anticipation of this instruction.

X15b and X15c exist because the subset check proved bypassable by container-wrapping: inferring structure from a value’s type, it passed X15’s leak wrapped in a list or dictionary—{“national_id”: [“000-11-2222”]} walked as a structural envelope, no unexpected fields reported. The corrected check tests every key against the requested set, recursing only into a frozen vocabulary of envelope names, and rejects both, naming the leaked key; a gate defeated by adding two characters survived because no adversary case had probed it.

Policy evaluation averaged 0.009 ms (95% CI 0.008–0.010) on a co-located engine, roughly one part in 2,600 of the end-to-end figure (Table 4). The paced privileged-update and negotiation series follow multi-second idle periods inside provider rate limits, so their means, not comparable with the unpaced reads, are reported for their intervals—unavailable from the earlier single-sample versions.

5.2. M1—Exposed Interface Surface

M1 claims not fewer moving parts but that growth does not widen the exposed surface. The REST baseline exposes five business operations (person search, person read, single-field read, note creation, status update), each a contract integrators must track (a sixth operation, a sixth contract), while SA2A exposes one operational channel (POST /messages) for every capability and role plus eight fixed auxiliary protocol endpoints: two pairing, two discovery and synchronization, three loopback-only approval, one health check. Adding a capability adds a registry entry, not an endpoint.

5.3. M2—Integration Effort

The invocable surface to learn is 29 logical lines for the REST client (five per-endpoint methods) against 192 for SA2A’s (pair, discover, invoke, resume); whole-library counts are 179 against 824, SA2A’s larger because verification, negotiation, and synchronization move into the client. At the margin, a REST capability costs a new client method (mean 5.8 logical lines) plus redistribution to every integrator; a SA2A capability costs zero, the generic invoke() serving anything discovered from the registry.

5.4. M3—Payload Minimization

For the same restricted-role person search with one seed match, both systems return exactly 73 bytes—42.9% of the 170-byte full record, the requester’s three authorized fields—a tie: the baseline’s minimization is real. REST minimization is per-endpoint DTO code the integrator must trust and the provider maintain field by field; SA2A’s, policy-driven per requester and re-applied server-side every call, makes profile changes without endpoint edits. The signed envelope adds 624 bytes of metadata (signature, nonce, expiry, correlation)—the wire cost of the guarantees probed in M6.

5.5. M4—Latency

Because the design interleaves the two systems, the comparison is a paired difference over iteration indices: +15.6 ms, 95% CI 15.0–16.1, t = 50.91 on 49 degrees of freedom, an overhead of +313% (Table 5).

It supersedes a previously reported +24.4 ms (+469%)—a methodological defect found and fixed in this revision, not a change in the system. That run discarded only three warmup calls—too few, by the drift statistic now computed for every series: REST slowed 1.17 ms and SA2A 5.65 ms between halves (22.5% and 19.1% of their means), roughly a third of the reported steady-state cost being within-run drift. After twenty warmups both series are steady (drift −0.13 ms and −0.53 ms) and the overhead settles at +15.6 ms. Warmups and timed iterations share one 60-per-60-second budget on both systems, so the harness drains a rate window after warmup, keeping processes warm and discarding only the rate counter.

The deployed two-hop path, routed through the requester’s own operator endpoint, is Table 5’s slowest series; the earlier three-sample version’s 25.3 ms—faster than the one-hop path it contains—was an artifact of too small a sample, resolved rather than explained away by the larger series.

Impact depends on call volume per unit of work: at roughly one cross-organizational call per operator action—the intended domain—a 20 ms call vanishes into surrounding human and network latency; at internal service-to-service rates a fourfold multiplier is decisive, and nothing SA2A adds compensates.

5.6. M5—Evolvability

Adding a capability to the REST baseline took six manual steps—server data-layer edit, route edit, redeploy, client method edit, client redistribution to every integrator, contract re-synchronization by each consumer. In SA2A it took zero manual steps and zero client code changes: the signed update arrived automatically, entered the requester’s cache, and ran through the unmodified generic invoke(); the unauthorized requester never received it, its leaked-copy probe drawing CAPABILITY_NOT_AUTHORIZED. Deploying the execution handler is provider-side in both architectures and excluded from the comparison.

Against /api/v2, which renames a query parameter and a DTO field, the unmodified REST v1 client broke on all five operations in three ways: the search failed loudly (HTTP 422); the person read failed silently, HTTP 200 with the renamed field read as null—data corruption with no error signal, a structural consequence of field names living in client code; the other three returned 404, the v2 module implementing only the two read endpoints.

5.7. The Evolution Probe: The Same Question Asked of SA2A

The earlier version of this work answered the counterpart SA2A question by assertion; the evolution probe measures it: a field is removed from a capability and from the requester’s profile, the old definition replaced rather than supplemented, the provider restarted on the broken registry with unmodified server code—only configuration data changed, the client never edited.

The next call fails loudly: the cached capability version no longer exists (Table 6); after the signed update, loudly again, the hard-coded field list still requesting a field the profile no longer grants; after re-discovery it succeeds with the new fields. No stage returned success while quietly withholding the requested field: zero silent failures, against one of five for REST. Recovery: zero client edits, one signed protocol exchange.

The comparison is not perfectly symmetric: REST’s change renames a wire-contract field; SA2A, with no per-operation wire contract to rename, took the equivalent change where it keeps its contract, the capability registry. The probe establishes something narrower than “SA2A does not break”—it broke, twice—and more useful: the breaks were detectable, nameable, and recoverable without shipping new code.

5.8. Where the Overhead Actually Goes

Table 7 attributes a 20.4 ms measured call to its components.

A single fsync-bearing SQLite commit, 2.18 ms (95% CI 2.09–2.30), is about twenty times an Ed25519 verification (103 µs), forty times a signature (52 µs), 340 times a policy evaluation (6.3 µs). Table 7’s write counts, read from the code, match rows written during the timed loop: eight audit and two nonce rows per iteration on the provider, two and one on the requester.

The residual is reported with its sign, not redistributed; priced at the edge of every primitive’s interval it lies between 0.72 and 2.43 ms. Its likely contributors—response-envelope serialization, per-request ASGI and routing work that the parse-rejected rung short-circuits, and process and event-loop scheduling—were not measured and are conjecture, not attribution. The positive sign is expected: warm single-threaded Layer-1 measurements lower-bound the same work in a loaded server process.

This reframes the least flattering number: the overhead is not the price of verification but of an unbatched, synchronously committed audit record written eight times per call. Batching, group commit, and asynchronous journalling are standard remedies, none applied, so 20.4 ms is an unoptimized upper bound, not a floor; a deployment can keep every check yet recover most of the overhead through audit persistence alone, at a tamper-evidence-granularity cost to be argued separately.

5.9. Ablation over the Response Gate

Until this revision the response gate—the paper’s novelty claim—had no attributed defensive value; the second ablation axis supplies it. Thirteen configurations by twelve attacks give 156 cells (Table 8); a mirror control reproduces the production gate verdict for verdict, an honest-response control confirms no configuration rejects a legitimate answer.

First, every one of the six checks is load-bearing: each single removal admits at least one attack no other check catches. Unlike the provider-side study, which found a redundant layer, this ablation finds no removable component: the stronger result, a minimal mechanism. Second, the checks are strictly additive: the degraded-reason-code column is empty in every cell and each compound removal admits exactly the union of its singles—no check backstops another. Third, only R6 leaks field values; the other five admit false, stale, misattributed, or duplicated answers without disclosure.

A fair test required extending the battery: the shipped response attacks exercise only R3, R5 and R6, so six probes (G1–G6) were added—a response attributed to a third agent, another addressed to one, one expired by thirty minutes, one dated ten minutes ahead, an answer from an unrelated correlation chain, and a payload with a status outside the frozen vocabulary. Without them, R1, R2 and R4 would have scored redundant for want of an attack—a claim about the battery, not the gate.

On the honest path the gate costs 4.54 ms (95% CI 3.99–5.10) of a 15.9 ms round trip, almost all in R5’s response-replay check, a durable nonce commit at +4.10 ms (95% CI 3.34–4.86); the other five checks’ intervals span zero against a ±0.19 ms resolution from a null comparison.

Finally, a limit: in all 42 admitted cells the outbound request was validly signed, on an active pairing, and inside its own field profile—one the provider’s own layers would have allowed, so none would have caught these attacks. The claim is a derivation from request-side measurements, not an independent one, and cannot be measured independently—in this threat model the party whose minimization would have to catch the leak is the compromised provider itself.

5.10. Ablation over the Provider’s Verification Layers

The provider-side ablation asks what each of six verification layers buys on the request path: twelve configurations in fresh sandboxes, three rounds each, order randomized per round (Table 9).

First, five of six layers carry attributable value: single removals let a forged identity, expired and far-future messages, and a replayed duplicate execute, while removing policy let an unauthorized update reach the database, collapsed negotiation into generic INVALID_PARAMETERS failures, and disclosed the full record, including national_id, phone_number, and address.

Second, the pairing gate is the exception, and the ablation shows it: removing L5 alone admitted nothing—the sender-known check (L1) already rejects unpaired senders. L5 is deliberate defense in depth, the only layer this study cannot justify on measured evidence.

Third, the executed/degraded distinction matters: removing L1 admitted nothing, the fail-closed signature check rejecting the same probes with INVALID_SIGNATURE rather than PAIRING_REQUIRED—lost diagnostic precision, not security—and with all cryptography removed, tampering was still caught by policy. Only the fully open configuration executed a majority, six of nine, the seventh and eighth stopped by the harness’s disabled-policy stub; eight breaches would overstate, zero would understate; both counts are reported.

Fourth, the study cannot resolve per-layer latency cost; the reason is instructive. An earlier version had every weakened configuration running slower than the full pipeline—an impossible result traced to instrumentation: each disabled layer wrote a hash-chained audit record per request, and at 2.18 ms per durable commit the penalty tracked the count of disabled layers (r = 0.93, 2.77 ms per layer), not the cost of those removed. With that record off the per-request path, fully open is now measurably fastest—−5.10 ms (95% CI −5.84 to −4.36) against the full pipeline—as the design predicts. Individual layers remain unresolvable: single configurations move up to 14 ms between rounds in the ordering audit, between-round machine state exceeding the per-layer effects, and three configurations’ intervals span zero. The honest reading: removing all verification is worth about 5 ms per call on this hardware, and no single layer’s cost separates from run-to-run variation at this sample size; Section 5.8’s decomposition, the better instrument, agrees—everything but the durable writes is sub-millisecond.

6. Discussion

6.1. Answers to the Research Questions

RQ1 is supported: pairing, capability discovery, negotiation, human-approval gating, registry synchronization, field filtering, and transactional rollback all behave as specified over a twelve-scenario end-to-end suite against live agents and a 473-test base, on commodity components — Python, FastAPI as transport only, SQLite, Ed25519 — with no bespoke infrastructure and no message broker.

RQ2 is supported. No designed attack succeeded in either direction across the eighteen-attack battery, and offline modification of a stored audit row was caught by chain verification. Removing the provider-side pairing gate (L5) admitted nothing, since the sender-known check already rejects unpaired senders: L5 is defense in depth rather than measured necessity. All six response-side checks are load-bearing: removing any one admits an attack no other catches, compound removals admit exactly the union of their singles, and no cell of the 156-cell matrix returned a degraded code. Only the payload-policy check R6 stands between a compromised provider and disclosure of field values; the other five admit false or stale answers.

RQ3 is supported, though the advantage is marginal rather than absolute. A second capability cost zero client-side steps and zero client code changes, against six manual steps and client redistribution for REST. Under a breaking provider change the SA2A requester failed loudly and recovered — VERSION_MISMATCH while uninformed, FIELD_NOT_AUTHORIZED after the signed update, full service after re-discovery — with zero client code edits, one signed exchange, and no silent failure; the unmodified REST v1 client broke on all five operations, one silently returning HTTP 200 with the renamed field read as null. But the up-front client surface is larger, and the advantage accrues across capabilities and provider revisions: integrate one capability once, from a provider that never changes, and the cost is never earned back.

RQ4 is supported, though the bill is not what the design predicts: +15.6 ms per call (95% CI 15.0–16.1, +313%) and +624 bytes per message. Durable hash-chained audit and nonce writes take 17.3 ms of the 20.4 ms call, or 84.6%; all cryptography — two signatures, two verifications, key parsing — 0.317 ms, or 1.6%, the cheapest component measured by over two orders of magnitude; and deterministic policy evaluation, field filtering, and the response gate’s own logic together 0.018 ms, or 0.1%. Six audit appends and two nonce commits per call dominate, each an fsync-bearing SQLite commit at roughly 2.1 ms — an implementation property, not an architectural one. Batching, WAL group commit, and asynchronous audit journalling are standard remedies, none applied here: 20.4 ms is an unoptimized upper bound, not a floor.

6.2. Where SA2A Does Not Win

Four results run against the architecture, bounding its applicability rather than listing defects to be engineered away.

The first is raw latency: a 20.5 ms signed, gated, audited call cannot beat a 4.96 ms REST call, and no tuning within this design closes that gap. At roughly one cross-organizational call per operator action — the intended domain — surrounding human and network latency absorbs the cost; at internal service-to-service rates the fourfold per-call multiplier is decisive and nothing SA2A adds compensates.

The second is client footprint: 824 logical LOC against the REST client’s 179, because signing, verification, replay defense, negotiation, and registry synchronization move into the client — a fixed investment, paid before the first call.

The third is operational novelty: REST tooling — gateways, dashboards, tracing, load generators, and above all developer familiarity — is decades deep against SA2A’s prototype and dashboard, so an adopter takes on an operational gap alongside the protocol.

The fourth is throughput, bounded by the same durable writes: eight synchronous commits per call at roughly 2.1 ms each put a single-threaded agent pair on this hardware near 30–40 requests per second. This is an analytic projection from the decomposition, not a measurement; no concurrency experiment was run, and contention on the SQLite writer under parallel load was not characterized.

6.3. Implications

The advantages concentrate where integration churn, authorization asymmetry, and auditability dominate — conditions typical of cross-organizational and public-sector integration [14,15]. Per-request rather than per-endpoint filtering cuts over-disclosure and DTO maintenance, mutual zero-trust closes the compromised-provider direction that endpoint-centric models leave to deployment discipline, and deterministic policy keeps decisions reproducible where they must be explained to auditors rather than approximated by models [3,8].

Because the cost is dominated by durable journalling rather than verification, guarantees and performance tune almost independently: the response gate costs 4.54 ms of a 15.9 ms round trip, but 4.10 ms of that is R5’s nonce commit and the other five checks’ intervals all span zero at the measurement’s ±0.19 ms resolution, so a deployment can keep every check and still recover most of the overhead by changing only how it journals.

6.4. Threats to Validity

Measurements come from one prototype on one machine, so absolute latencies will vary, though interleaving and fresh-sandbox boots control the relative comparison. All measurement is over loopback, so the reported relative overhead is an upper bound: real network latency is common to both architectures and would shrink the ratio, not the absolute difference. Consecutive iterations are correlated, so nominal sample sizes overstate independent information; effective sample sizes are reported alongside them, and the correlated series additionally summarized with a moving-block bootstrap. The paced series — the privileged update batch and the negotiation round trip — sleep between calls for the provider’s rate limits, so those calls are comparatively cold and their means are not comparable with the unpaced read series.

The REST baseline, though deliberately strong, is one realization of the standard toolkit; a managed gateway would narrow the M6 gap but not M5’s structural breakage, which follows from field names living in client code. The v2 module implements only the two read endpoints, so three of the five REST breakages are route-absence 404s, and only the two read breakages, the loud 422 and the silent corruption, are realistic. The adversary battery is designed, not exhaustive: eighteen attacks across both directions are not penetration testing, and absence of success is evidence about these attacks only.

Three limitations attach to the response-gate study. Its provider-side counterfactual — that no provider-side layer would have caught any of the 42 admitted cells — is derived from request-side measurements rather than measured independently, and cannot be: there the adversary is the provider whose layers would do the catching. One of the two requesters pins the provider’s public key instead of resolving it through the pairing store, so key revocation does not reach that agent’s response gate — a prototype convenience, not a protocol property, but one narrowing what the gate enforces there. And the offline environment ships no coverage or mutation-testing tooling, so the test count measures the suite’s size, not its adequacy.

Policy evaluation is deterministic by design; learning-based intent interpretation would introduce misinterpretation and prompt-injection risks deliberately excluded from v0.1, and these results say nothing about that setting.

7. Conclusion and Future Work

SA2A demonstrates that independently developed systems can integrate through boundary agents exchanging signed, intent-level envelopes rather than operation-specific API calls, under deterministic policy, provider-guided negotiation, human-approval gating, tamper-evident audit, and mutual zero-trust verification. The prototype rejected all eighteen designed attacks, the ablations attribute value layer by layer, and the evolution probe shows requesters surviving a breaking provider change without client edits. The price is +15.6 ms per call, +313%, and +624 bytes per message, and its composition — 84.6% durable journalling, 1.6% cryptography, 0.1% policy — locates that cost in an implementation choice rather than the architecture. Where call volume per unit of work is high, REST remains the right answer.

Five directions follow. An offline store-and-forward mode would carry signed envelopes as encrypted packages for isolated and intermittently connected environments. Federated multi-organization deployments would extend the approval state machine to cross-institutional policies. Batched or asynchronous audit journalling, the change the decomposition identifies as recovering most of the measured overhead, should be evaluated against the tamper-evidence guarantee it relaxes. A static reachability pass would enforce the data-not-commands rule mechanically, replacing the prototype’s dynamic evidence. A formal verification pass over the pairing and gate state machines would establish the properties the ablations can only sample.

The protocol specification, prototype, experiment harnesses, adversary toolkit, and the generated result files behind every figure constitute a reproducible package available from the authors.