Agentic AI Security Testing: Evidence that makes AI agents testable

In the Model Context Protocol (MCP), a host creates a client for each server. The host is expected to enforce authorization, consent and security boundaries. Tools are discovered and invoked through structured protocol operations. Their descriptions and annotations can influence model behavior and are not inherently trustworthy. An incident therefore spans content ingestion, planning, approval, tool invocation and a remote effect. It does not remain inside a single model call.

Three observable transitions follow from this architecture: host→client, client→server and server→effect. A trace that ends at a successful tool response can still miss whether an external write occurred, was duplicated, or reached a different target. Ordinary component logs or a shared trace identifier rarely record whether the approval matched the principal, arguments, target and delegated authority at execution time.

Three research questions

• RQ1: Which evidence profiles reconstruct and uniquely attribute an effect under controlled telemetry faults?
• RQ2: Do threat-derived semantic bindings improve security detection beyond correlation alone?
• RQ3: What does the evidence cost, and which failure modes remain?

The contribution has three parts: a four-stage Evidence Contract that maps MAESTRO and STRIDE findings to runtime fields; a deterministic fault-injection corpus with six attack families, closely matched benign variants and a ground-truth ledger that the reconstructor never sees; and a comparison of fragmented, correlated, causal and threat-guided profiles across 3,024 cells.

MAESTRO organizes threats across seven interacting layers of an agentic system and emphasizes cross-layer effects. The layers range from foundation models through data operations, agent frameworks, deployment infrastructure, evaluation and observability, and security and compliance to the agent ecosystem. STRIDE adds six property categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege.

The paper uses both frameworks to select boundary-relevant scenarios. It does not claim empirical validation of the frameworks. The OWASP Top 10 for Agentic Applications 2026 serves as a cross-check for the vocabulary, including ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI06 Memory & Context Poisoning and ASI08 Cascading Failures; they are treated there as system-level concerns.

Each event has an immutable event identifier, component, stage, schema version and timestamp. Correlation fields add trace, span, parent and action IDs. The threat-guided fields bind facts whose equality or ordering implements a test oracle. What matters is that the tool event repeats the exercised values rather than merely pointing to the decision. Only comparing adjacent stages exposes substitutions that remain invisible in correlation-only traces.

What the contract deliberately does not record

No profile records hidden chain-of-thought. Decision evidence is restricted to explicit policy outcomes, concise reason codes, approved attributes and hashes suitable for controlled testing. Sensitive prompt content or model reasoning need not be stored. Provenance labels, stable identifiers and keyed digests are sufficient for tests and reduce disclosure.

Since September 2026, ACS has been a project of the OWASP GenAI Security Project, at Level 2 (Incubator) according to its own project metadata; specification v0.1.0 dates from 5 June 2026, the current release tag is 0.1.2. It grew out of the Agent Observability Standard (AOS). Under ACS, an agent is considered trustworthy if it is inspectable, traceable and instrumentable. Operators should thus be able to determine after the fact what an agent did and why, and to limit in advance what it may do.

The three pillars

Wire, provenance and audit chain

• Wire format JSON-RPC 2.0. Method namespaces: steps/* (hooks), protocols/* (encapsulated MCP; A2A is reserved for v0.2), agbom/*, system/* and handshake/*. On a version conflict, the handshake ends with UNSUPPORTED_VERSION. The spec prose still assumes MCP mechanisms predating revision 2026-07-28, and whether MCP wrapping belongs to ACS-Core is contradictory in the spec text; MCP tool calls may also be carried via steps/toolCallRequest/-Result.
• Provenance is a factual origin label on data-carrying fields. It is set by deterministic framework code, never by the LLM: origin (user_input, system, tool_output, retrieved, agent_generated, a2a_inbound, external), source_id and derived_from as lineage edges.
• Under the acs-provenance profile, field-level provenance is mandatory for every data-bearing field of the session, including every argument of steps/toolCallRequest. The trust classification is made by the Guardian according to local policy; it is not a field in the v0.1 schema.
• Every response for a content-bearing step carries a chain_hash: the rolling SHA-256 head of the audit chain. policy_references (including the optional policy_version) and cited_provenance_ids make the decision replayable.
• Signatures are crypto-agile and mandatory in ACS-Core: every request and every response is signed over the canonical envelope; HMAC-SHA256 with an HKDF-derived session key is the baseline that satisfies this. It makes tampering on the network evident, but not a compromised Guardian. Non-repudiation only comes with the acs-crypto profile: ML-DSA-65 (mandatory) and SLH-DSA-128s (recommended as backup).

Why the effect gap is structural

ACS hooks fire inside the agent runtime. steps/toolCallResult reports what the tool returns to the agent. It does not report what actually happened at the target system. The paper shows why this difference matters: a trace that ends at the successful tool response can miss duplicate writes or redirected targets. Effect evidence must therefore come from a second source that is independent of the agent. It is bound to the ACS trace via action and request IDs.

Why fail-open is the F1 problem

If the Guardian is unreachable under failure posture proceed, the action continues. ACS does require logging every fail-open proceed as an audit event, but no decision receipt with approval bindings is created. Operationally, this corresponds to fault F1 from the experiment (VamiSec interpretation). If the decision events are missing, exact reconstruction and attribution fall to 0% and the recall of the threat-guided profile to 50%. An ACS deployment that takes security testing seriously therefore negotiates on_decision_failure: deny (in the reference implementation: ACS_ON_DECISION_FAILURE=deny), sets the startup posture refuse on the Observed Agent and treats a missing receipt as a test failure, not as a gap in the log.

The corpus contains six workflow families, each with four unsafe and two closely matched benign variants: 36 templates, of which 24 are unsafe and 12 benign. Three deterministic repetitions yield 108 workflow instances. The repetitions vary identifiers and event jitter. They are a reproducibility check, not independent statistical samples.

A trusted generator emits canonical, MCP-shaped JSON events. Separately, a ground-truth ledger is produced containing expected event identities, parent edges, unsafe labels, the violated rule and the first violation stage. Before reconstruction, private case IDs are stripped from the observable events. Workflows in the same family share an intentionally overlapping time window. This is a difficult case for time-nearest attribution.

Reconstruction and metrics

• P0 groups an effect with the temporally nearest tool, P1 by trace ID. P2 and P3 follow parent edges and fall back to action IDs when an effect parent is missing.
• Exact reconstruction requires prompt, decision, tool, all effects and, in P2/P3, the expected parent edges.
• Unique attribution requires all expected effects to map to exactly the correct prompt, decision and tool, even if a parent edge is missing.
• Recall and precision use the unsafe label, the benign false-positive rate the 12 benign templates. Correct-rule and first-stage rates test the diagnosis.

The implementation uses only the Python standard library. Two clean executions produced byte-identical configuration, case, aggregate and summary hashes. Three unit tests check matrix size and balance, deterministic outputs and the P3-versus-P2 recall comparison.

P0 never achieved unique attribution because temporally overlapping workflows were merged. Its apparent recall of 84.5% is not useful security performance: incorrectly merged chains raised alerts on 85.7% of benign cases. P1 detected only duplicate-effect cases. P2 raised unique attribution to 85.7%; security recall remained at 16.7%. P3 retained P2's attribution and raised recall, correct-rule rate and first-stage localization to 92.9%.

Fault sensitivity

1. 1
   F0Unchanged evidence

   P1 through P3 reconstruct and attribute every workflow. P3 achieves 100% recall and precision with no false positives.

2. 2
   F2Trace split at the tool boundary

   P1 loses reconstruction and attribution completely. P2 and P3 remain at 100% because parent and action IDs bridge the modified trace boundary.

3. 3
   F3Lost effect parents

   Exact reconstruction of P2/P3 falls to 0%; unique attribution stays at 100% via the action fallback.

4. 4
   F4–F6Time offset, duplicates, action-ID swap

   No loss for P2/P3: the remaining evidence yields an unambiguous path, and corruption checks expose the injected inconsistency.

5. 5
   F1Missing decision events

   The dominant residual weakness: reconstruction and attribution fall to 0% in P1 through P3, and the recall of P3 to 50%. Source authority, memory and duplicates remain detectable. Approval, scope and target binding lose their comparison point.

P3 adds 1,682 bytes (about 1.64 KiB) over P0 and 1,096 bytes over P2. A collector using the same event representation would retain about 3.55 times the canonical bytes of P0, or 1.88 times those of P2, for a median-sized workflow. These values answer RQ3 as a serialization-volume comparison. They do not measure latency, CPU, transmitted traffic, compression, indexing or monetary cost.

Operating rules from the paper, translated to ACS

• Complete decision, invocation and effect receipts first for privileged operations: in ACS terms, for capabilities such as filesystem.delete, network.egress or process.execute.
• Set explicit retention limits. Deduplication, compression and keyed digests can reduce volume but must be measured separately.
• Anyone who drops an invariant-relevant field or samples away Decision Receipts changes the Evidence Contract and must re-evaluate. F1 shows what is lost then.
• Model integrity, clocks, retention and access control separately. ACS offers the HMAC baseline (acs-core), asymmetric or PQC signatures (acs-crypto), request_hash (acs-audit) and the chain_hash of the audit chain for this.

1. 1
   Step 1Translate threats into hypotheses

   Walk through MAESTRO layers and STRIDE properties for each agent workflow. For every dangerous transition, formulate a tuple H = (boundary, precondition, invariant, evidence, oracle).

2. 2
   Step 2Define ACS hooks and profiles

   ACS-Core as the baseline, plus the acs-trace and acs-provenance profiles. In addition to the six mandatory Core hooks (sessionStart, userMessage or agentTrigger, toolCallRequest, toolCallResult, agentResponse, sessionEnd), instrument steps/knowledgeRetrieval, steps/memoryContextRetrieval and steps/subagentStart — and check that the Guardian lists them in methods_evaluated (otherwise they are ALLOW-by-default).

3. 3
   Step 3Define the Decision Receipt

   Principal, policy version, reason code, operation, normalized target, argument digest, capabilities, delegation depth, expiry and idempotency in policy_data. Persisted and bound to request_id and chain_hash.

4. 4
   Step 4Harden the failure posture

   Set the failure posture to fail-closed: on_decision_failure: deny in the ServerHello (reference implementation: ACS_ON_DECISION_FAILURE=deny) and the startup posture refuse on the Observed Agent in case the handshake itself fails. Sign envelopes. A missing receipt is a test failure.

5. 5
   Step 5Connect an independent effect sink

   Gateway, database or sink audit supplies observed target, operation digest and idempotency key, correlated via the action ID.

6. 6
   Step 6Negative tests with benign twins

   For each family, unsafe and closely matched benign cases, such as permitted alias resolution or repeated reads. Freeze predicates before testing.

7. 7
   Step 7Two CI gates

   Gate 1 reconstruction: required stages and parent edges complete, otherwise quarantine. Gate 2 correctness: invariants satisfied, otherwise abort with the violated rule and first stage.

8. 8
   Step 8Inject telemetry faults

   Run F1 through F6 against your own pipeline regularly. A test that is still green under F1 does not check approvals.

The study uses synthetic deterministic fixtures, handcrafted invariants and fixed event schedules. It executes no LLM, no MCP implementation, no OAuth, no policy engine and no external service. It neither measures prompt-injection success nor demonstrates that a control prevents an effect. Precision and recall apply only to the six encoded families. Because the evaluator was designed from the same threat hypotheses, the experiment tests evidence sufficiency and implementation consistency, not the discovery of new threats.

• The ground-truth ledger is logically separated but generated by the same codebase. Independent implementations, property-based mutation and real protocol captures would reduce common-mode error.
• Telemetry is assumed to be authentic. Spoofed producers, log truncation beyond the injected faults, compromised collectors and cryptographic verification remain open.
• New threat classes need their own hypothesis, fields, oracle and independently authored tests. Resource exhaustion, for example, requires budget and consumption evidence; forged telemetry requires producer identity and integrity verification.

Disclosure from the paper: OpenAI Codex was used for literature organization, implementation scaffolding and review of the synthetic evaluation code, initial drafting and language revision, and formatting. The research question, threat model, execution, checking of the results and sources, and all final decisions rest with the author.