Governed agents

Executive thesis

Valid as of 2026-08-23.

Dataheart should treat the model as an untrusted, nondeterministic proposal engine—not as an authorization authority, transaction coordinator, identity provider, memory curator, or audit system.

The durable product boundary is therefore a vendor-neutral governance envelope around every agent run:

1. Establish the human/service subject and the distinct agent/workload actor.
2. Let a model propose a typed action.
3. Authorize the exact action, arguments, destination, data, purpose, and risk outside the model.
4. Issue a short-lived, audience-bound, attenuated capability.
5. Execute through a sandboxed tool broker.
6. Record a tamper-evident decision and execution receipt.
7. Treat tool output and persistent memory as potentially hostile data.
8. Re-evaluate behavior whenever the model, prompt, tool, policy, or memory implementation changes.

MCP and A2A materially reduce integration lock-in, but neither is a security model. MCP standardizes tool/context exchange; A2A standardizes agent-to-agent exchange. Identity, authorization, information-flow control, transaction semantics, evidence, memory governance, and human oversight remain Dataheart responsibilities. The NSA’s May 2026 assessment similarly concludes that MCP’s security posture remains uneven and implementation-dependent, despite calling it a de facto integration standard. NSA, MCP Security Design Considerations

The dual deployment requirement is feasible if Dataheart owns canonical contracts and tests rather than relying on nominal API compatibility:

• Microsoft-native: Entra Agent ID/managed identities, Microsoft Foundry, Agent Framework, Azure policy and security services.
• Self-hosted/open: OIDC/OAuth, SPIFFE/SPIRE, an external policy engine, open workflow runtime, sandboxed Kubernetes or equivalent, OpenTelemetry, customer-controlled stores and models.

Behavioral portability will never be automatic: different models make different tool choices and react differently to attacks. Portability must mean “same governance semantics and conformance suite,” not “identical prompts produce identical behavior.”

Classification used below:

• Established practice: grounded in mature security/distributed-systems practice, final standards, or binding regulation.
• Emerging practice: implemented and evidenced, but specifications, operations, or assurance remain immature.
• Hypothesis: recommended Dataheart architecture requiring customer validation.
• Vendor claim: first-party product or project assertion not yet equivalent to independent assurance.

State of the art 2024-2026

2024

• Established: Production architectures increasingly separated bounded workflows from open-ended agent loops. Deterministic workflows remained preferable where the sequence, authorization, and failure handling could be specified in advance.
• Established evidence of risk: AgentDojo introduced 97 realistic tasks and 629 adversarial test cases. In that benchmark, contemporary agents solved fewer than 66% of tasks even without attacks; attacks against the best agents succeeded in fewer than 25% of cases, and a detector reduced benchmark attack success to 8%. This is evidence both of vulnerability and of limited baseline reliability—not evidence that every agent is trivially compromised. The paper explicitly warns against evaluation using only its default, non-adaptive attacks. AgentDojo, NeurIPS 2024
• Emerging: MCP created a common agent-to-tool protocol and began displacing bespoke connector APIs.
• Binding where applicable: The EU AI Act established requirements for high-risk AI systems including automatic logging, effective human oversight, robustness, and cybersecurity. Article 14 requires that authorized humans can disregard, override, reverse, intervene, or safely stop the system. These obligations apply according to the Act’s classification and role rules; they are not automatically applicable to every Dataheart agent. Regulation (EU) 2024/1689
• Voluntary governance baseline: NIST’s Generative AI Profile extended the AI RMF across the lifecycle, emphasizing governance, measurement, incident handling, third-party risk, testing, and evidence. It is guidance, not a certification or proof of safety. NIST AI 600-1

2025

• Established: RFC 9700 consolidated OAuth 2.0 security best current practice. Relevant controls include PKCE, exact redirect validation, audience/privilege restriction, short-lived credentials, asymmetric client authentication, and sender-constrained tokens through mTLS or DPoP where justified. RFC 9700, January 2025
• Emerging: MCP 2025-11-25 incorporated a stronger HTTP authorization profile around OAuth, protected-resource discovery, audience binding, incremental scopes, and PKCE. Authorization nevertheless remains optional at the MCP implementation level, particularly outside HTTP transports.
• Established implementation warning: MCP explicitly forbids token passthrough and documents confused-deputy, SSRF, session hijacking, unsafe local servers, OAuth URL injection, and excessive-scope failures. Local stdio servers commonly inherit the client process’s privileges and therefore require OS-level isolation. MCP Security Best Practices
• Emerging research: CaMeL moved prompt-injection defense from prompting toward explicit control-flow, data-flow, provenance, and capability enforcement. Version 2 reports 77% task completion with its scoped security guarantee versus 84% for the undefended system, but median token use rose by 2.82× for input and 2.73× for output. It assumes trusted user intent and uncompromised memory, does not stop all text-to-text manipulation or phishing, requires policies to be authored and maintained, and acknowledges side channels and compositional attacks. CaMeL, arXiv v2, 24 June 2025
• Vendor implementation, not invariant: Hosted agent platforms began exposing tool allowlists, approval hooks, guardrails, tracing, and evals. For example, OpenAI’s current Responses API can restrict allowed MCP tools and require approval. These controls are useful but proprietary in configuration and semantics. OpenAI Responses API reference

2026

• Vendor/project claim: A2A v1.0 describes itself as production-ready and adds signed Agent Cards, multi-tenancy, version negotiation, and several protocol bindings. A signed card can authenticate metadata provenance; it does not grant business authority, validate a live runtime, or prove that an agent will obey policy. A2A v1.0 announcement
• Vendor implementation: Microsoft Entra Agent ID formalizes agent identities and blueprints. Its delegated form can represent a user as subject and an agent as actor; autonomous operations use an agent identity. This is a useful semantic model, but it is currently Microsoft-specific and tied to Entra tenant/control-plane behavior. Microsoft Entra agent identities
• Vendor implementation with explicit limitations: Microsoft Foundry can inspect user input, tool calls, tool responses, and output, but agent guardrails and several intervention points remain preview features and do not cover arbitrary agents merely registered in the control plane. Preview features lack production SLA guarantees. Microsoft Foundry guardrails
• Emerging open implementation: Microsoft Agent Framework is MIT-licensed and actively adding A2A, OpenTelemetry, workflow, and Foundry integrations. Open licensing helps code portability but does not make Microsoft-hosted identity, memory, policy, or operational behavior portable. Agent Framework releases
• Emerging attack evidence: Bad Memory found that pre-planted instructions in persistent memory could affect current and future sessions. In its small synthetic evaluation—ten trials per model/goal—single-session mean attack success ranged from 23.3% to 63.3%, with substantial model and attack variation. The researchers could not reliably make the agents write malicious trusted memory from external content, so this is an existence result and warning, not a population estimate. Bad Memory, 16 July 2026
• Emerging observability: OpenTelemetry now models agent, workflow, planning, tool, and memory operations, but agent semantic conventions remain under development. The specification also warns that captured inputs and outputs may contain sensitive or personal data. OpenTelemetry GenAI agent spans
• Counter-evidence to “MCP equals enterprise security”: The NSA documents optional authentication, inconsistent access control, weak approval workflows, tool-name/path confusion, token lifecycle gaps, session attacks, parameter injection, registry risk, local RCE, and incomplete auditability. Its recommendation is to add gateways, validation, isolation, egress control, signing, inventory, logging, and scanning outside MCP.

Load-bearing concepts

1. [Established] Separate inference, authorization, and execution.The model may recommend or propose. It must not mint credentials, decide its own entitlement, expand scope, suppress required approval, or execute directly against sensitive systems.

2. [Established] Represent subject, actor, resource, and purpose separately.A governed action should identify:

   • the human or calling service whose authority is being used;
   • the agent/workload that proposed and executed it;
   • the sponsoring owner and tenant;
   • the resource and action;
   • the declared business purpose;
   • applicable data classification and policy version.

   Shared human credentials destroy this distinction and make investigation, revocation, and non-repudiation unreliable.

3. [Established with emerging agent application] Authorize after argument resolution.Tool allowlisting alone is insufficient. Risk depends on exact parameters: “send email” differs radically depending on recipient, attachment, data classification, and tenant. Authorization must occur on canonicalized arguments immediately before execution.

4. [Hypothesis supported by CaMeL] Use attenuated action capabilities.A capability should be unforgeable, single-use or tightly bounded, and bind at least:

   subject, agent, tool-id, tool-version, action, resource, purpose, argument-hash, audience, expiry, run-id, policy-decision-id, and approval-id.

   Broad OAuth access tokens must never be placed in the model context. A broker should exchange the approved capability for downstream credentials.

5. [Established] Prefer deterministic workflows with bounded agent islands.A durable state machine should own ordering, retries, deadlines, idempotency, compensation, budgets, and escalation. Models should handle ambiguity—classification, extraction, planning, or drafting—inside explicit stages.

6. [Emerging protocol] Treat MCP metadata as untrusted.MCP tool annotations are explicitly untrusted unless the server is trusted. A readOnlyHint is neither an entitlement nor proof of low risk: a read-only tool can exfiltrate highly sensitive data. Pin tool identity, publisher, version, schema, and effect classification; invalidate approvals when any changes. MCP Tools specification

7. [Established] Isolate effectful execution.Enforce filesystem, process, CPU, memory, time, network, DNS, and destination restrictions. Default-deny egress for high-risk agents. Local MCP servers require the same software-supply-chain controls as plugins or downloaded executables.

8. [Established] Human oversight must be meaningful and risk-based.Approval should display the exact target, data leaving the boundary, side effects, reversibility, and capability expiry. Approval of a connector or broad tool category must not silently approve later schema or behavior changes.

9. [Emerging] Split memory by trust and function.Keep separate stores for:

   • ephemeral scratch state;
   • session conversation state;
   • retrieved external knowledge;
   • durable customer facts;
   • user preferences;
   • operating instructions and policy.

   Retrieved content must never promote itself into instruction or policy memory. Durable instruction changes require provenance, review, versioning, expiry, revocation, and rollback.

10. [Established goal, emerging schema] Audit observable decisions, not hidden reasoning.Record prompts or hashes where lawful, model and prompt versions, retrieved evidence, action proposals, policy inputs, policy outputs, approvals, capabilities, tool calls, results, costs, errors, and state transitions. Hidden chain-of-thought is provider-dependent, sensitive, incomplete, and unsuitable as the primary audit record.

11. [Established] Evaluate system and process separately.Measure task completion independently from tool selection, argument correctness, policy adherence, data leakage, unauthorized effects, reversibility, and cost. A safe agent that never completes work is not useful; a useful agent that occasionally violates authorization is not deployable.

12. [Hypothesis] Governance semantics are the portability boundary.Models and orchestration frameworks can change if the action proposal, policy, capability, evidence, memory, and evaluation contracts remain stable.

Reference patterns

Pattern 1: Governed propose-authorize-execute loop

flowchart LR
    A["Subject, purpose, and request"] --> B["LLM planner: proposal only"]
    B --> C["Canonical action proposal"]
    C --> D{"External policy decision point"}
    D -->|"Deny"| Z["Stop and record evidence"]
    D -->|"Approval required"| H["Human reviews exact effect"]
    H --> D
    D -->|"Allow"| E["One-shot attenuated capability"]
    E --> F["Sandboxed tool broker"]
    F --> G["Pinned tool or MCP server"]
    G --> I["Typed untrusted result plus provenance"]
    I --> J["Schema, taint, and policy validation"]
    J --> B
    C --> K["Append-only evidence ledger"]
    D --> K
    H --> K
    G --> K

Any new proposal produced after consuming tool data must be reauthorized. Tool output can inform a decision; it cannot authorize itself.

Pattern 2: Prepare-authorize-commit for external effects

For payments, messages, deletion, publication, account changes, or other consequential writes:

1. prepare(canonical_args) returns an effect preview without committing.
2. Dataheart hashes the preview, normalized arguments, tool identity, and version.
3. Policy and, where required, a human approve that exact hash.
4. The broker issues a one-shot commit capability with a short expiry.
5. commit(preparation_id, capability) performs the effect idempotently.
6. Execution produces a signed receipt and, if possible, a compensation reference.

This avoids approval race conditions and “approved one thing, executed another” failures.

Pattern 3: Bounded multi-agent delegation

For A2A or equivalent delegation:

• Treat discovery cards as untrusted metadata until publisher and signature are validated.
• Send a delegation contract containing task, purpose, maximum scope, data classes, budget, deadline, hop limit, evidence requirements, and caller identity.
• Do not forward caller credentials.
• The receiving agent reauthorizes locally and receives narrower credentials.
• Scopes, budgets, and deadlines must decrease monotonically across hops.
• Responses include provenance and execution receipts, not merely natural-language claims of success.

Pattern 4: Quarantined memory promotion

1. New observations enter an untrusted candidate store.
2. Automated extraction creates typed factual candidates with source provenance.
3. Conflicts, instructions, secrets, and high-impact preferences are rejected or routed to review.
4. Approved memory is versioned with tenant, subject, purpose, TTL, access policy, and source hashes.
5. Retrieval preserves trust labels and never silently converts external text into privileged instructions.
6. Revocation removes the item from both retrieval indexes and caches within a defined SLA.

Failure modes and counter-evidence

Failure mode	Why common controls fail	Required control
Indirect prompt injection	Delimiters, system prompts, and classifiers remain probabilistic; tool output is placed in the same semantic context as trusted instructions.	Quarantine untrusted data, separate control and data flow, authorize every effect outside the model, and test adaptive attacks.
Tool poisoning or post-approval drift	A server can alter descriptions, schemas, annotations, or available tools after installation.	Signed/pinned manifests; publisher trust; change review; invalidate grants and cached approvals on any material change.
Valid tool, harmful arguments	Tool allowlists check names rather than recipients, resources, amounts, or data flow.	Canonical argument authorization, destination/data classification, prepare-commit, one-shot capability.
Confused deputy and token passthrough	A proxy reuses or forwards a credential issued for another audience.	Audience-bound tokens, downstream token exchange, no passthrough, separate subject and actor, replay controls.
SSRF and unrestricted egress	MCP discovery and tools resolve attacker-controlled URLs; application checks miss DNS rebinding and encoding tricks.	Egress proxy, deny private/link-local ranges, validate every redirect hop, DNS pinning where needed, default-deny networking.
Local MCP server compromise	Local servers often execute with the host client’s filesystem and process privileges.	Signed packages, SBOM/provenance, explicit command preview, process sandbox, restricted filesystem and network, inventory and patching.
Approval fatigue	Repeated generic prompts train users to click through; a connector-level approval hides the real effect.	Risk-tiered approvals, exact effect diff, batching only for homogeneous bounded operations, approval expiry, measurable fatigue testing.
Memory poisoning	Persistent files and retrieval stores are often loaded as trusted context across sessions.	Separate trust tiers, reviewed writes, provenance, TTL, immutable policy memory, cross-session attack tests.
Multi-agent authority laundering	Downstream agents assume upstream validation and inherit excessive credentials or context.	Reauthorization at every trust boundary, attenuated delegation, hop limits, identity propagation, evidence verification.
Duplicate effects and runaway loops	Model retries and distributed timeouts cause repeated writes, cost explosions, or inconsistent state.	Durable orchestration, idempotency keys, retry budgets, deadlines, circuit breakers, compensation, maximum tool-call budgets.
Audit leakage	Full prompts, tool results, tokens, and memory copied into traces create a second sensitive data store.	Field-level logging policy, secret stripping, encryption, tenant isolation, retention limits, selective content capture.
False confidence from evals	Static attacks are overfit; LLM judges can be inconsistent; a single aggregate score hides authorization failures.	Adaptive red teams, deterministic state assertions, counterfactual cases, held-out attacks, independent utility/security metrics.
Model or prompt drift	A new model may improve task utility but worsen a particular attack or tool behavior.	Version pinning, shadow runs, conformance gates, rollback, per-model risk envelopes.

Important counter-evidence and limitations:

• AgentDojo’s default attacks succeeded in fewer than 25% of cases against its best agents, and one detector reduced this to 8%. Security claims must therefore specify the attacker, task distribution, and utility trade-off rather than implying universal compromise.
• CaMeL demonstrates that scoped, architecture-level guarantees can coexist with useful performance. It does not cover compromised memory, untrusted user intent, all semantic manipulation, policy mistakes, side channels, or every composition attack; it also incurs material token and engineering cost.
• Bad Memory could not reliably induce agents to overwrite their own trusted memory from external content. Its strong results concern payloads already present in persistent files, use small trial counts, and should be treated as emerging evidence.
• Microsoft Foundry’s tool-call and tool-response controls are useful but remain preview and platform-scoped. They cannot be Dataheart’s only authorization boundary.
• Human approval is not a security proof. Humans can misunderstand, over-trust, or become fatigued, and Article 14 of the EU AI Act expressly calls out automation bias.

Operational cost is load-bearing:

• Capability and information-flow systems require policy authoring, provenance propagation, exceptions, and customer-specific semantics.
• Extra classifiers, planners, validation models, and retries add latency and inference cost; CaMeL’s benchmark median was roughly 2.8× token usage.
• Approval queues add labor and can become business-process bottlenecks.
• Full traces create significant storage, privacy, retention, and discovery obligations.
• Self-hosting transfers spend from licenses to platform engineering, patching, model serving, GPU capacity, identity operations, red teaming, and on-call support.
• Microsoft-native deployment reduces integration effort but increases dependency on Entra, Foundry, Purview, Azure Monitor, proprietary preview lifecycles, regional availability, and licensing.
• MCP/A2A reduce connector and messaging lock-in, but model APIs, hosted memory, eval formats, approval semantics, and control-plane metadata remain non-standard.

Implications for Dataheart

Product role

Dataheart should be the customer-owned control and evidence plane around multiple agent runtimes, not another monolithic agent framework.

Its canonical artifacts should include:

• AgentDefinition: owner, sponsor, purpose, risk tier, permitted model classes, tools, memory classes, autonomy ceiling.
• ToolManifest: immutable tool ID, publisher, version, schemas, effects, resource reach, data classes, egress needs, reversibility.
• ActionProposal: canonical arguments, intended effect, source evidence, confidence, model/prompt versions.
• DecisionRecord: subject, actor, resource, purpose, policy version, decision, obligations, reason codes.
• CapabilityGrant: narrowly scoped, audience-bound, short-lived, input-hash-bound authority.
• ApprovalReceipt: approver authority, exact effect hash, timestamp, expiry, constraints.
• ExecutionReceipt: tool/version, normalized request, result hash, side effects, idempotency and compensation references.
• EvidenceBundle: linked decisions, provenance, model/tool/memory versions, costs and state transitions.
• MemoryRecord: fact/instruction class, source, trust, access policy, TTL, conflicts and approval.
• EvaluationPack: use-case tasks, adversarial cases, invariants, expected policy decisions and profile parity tests.

Autonomy ladder

• A0 — Inform: answer with evidence; no action proposal.
• A1 — Recommend: propose actions and consequences.
• A2 — Prepare: perform reads and reversible dry-runs; generate an exact effect preview.
• A3 — Supervised commit: execute a human-approved, hash-bound action.
• A4 — Bounded autonomy: execute within a narrow, pre-authorized domain, budget, duration, and resource set.

Security administration, identity changes, high-value payments, broad publication, destructive operations, and sensitive cross-boundary transfers should remain at A2 or A3 until domain-specific evidence justifies otherwise.

Vendor-neutral invariants versus profile choices

Vendor-neutral invariant	Fully Microsoft-native profile	Fully self-hosted/open profile
Distinct subject, agent actor, sponsor and tenant	Entra Agent ID, managed identity, OAuth/OBO, Conditional Access	OIDC/OAuth authorization server plus SPIFFE/SPIRE workload identity
Canonical action/PDP contract outside the model	Entra/RBAC, APIM policy, Azure Policy, Purview and Dataheart PDP	OPA/Rego or Cedar-compatible PDP with customer OIDC claims
Durable state machine owns retries and effects	Microsoft Agent Framework plus Durable Functions or Foundry runtime	Temporal, Argo Workflows, or a customer-controlled durable state machine
Model is replaceable behind a Dataheart adapter	Microsoft Foundry model endpoints and approved catalog models	Self-hosted vLLM/SGLang or pluggable external endpoints
MCP is mediated, not directly trusted	MCP behind APIM/Foundry tooling with Dataheart authorization	MCP behind a self-hosted gateway and policy enforcement point
Effectful tools use prepare-authorize-commit	Azure-hosted functions/APIs with idempotency and Key Vault	Containerized services with one-shot grants and customer secrets store
Filesystem and network isolation	Foundry hosted runtime where suitable; Azure Container Apps/AKS/Windows isolation; Key Vault	Kubernetes plus seccomp/AppArmor and optionally gVisor/Kata; customer secret manager
Customer-owned memory policy and provenance	Azure SQL/Cosmos DB/Search/object storage with Purview classification	PostgreSQL/vector/object store with row/column policy and provenance metadata
Portable trace/evidence schema	OpenTelemetry into Application Insights/Azure Monitor/Sentinel plus immutable Azure storage	OpenTelemetry Collector into customer observability/SIEM plus WORM-capable object storage
Continuous system/process/security evaluation	Foundry Evaluation/PyRIT plus the Dataheart conformance suite	AgentDojo-derived and customer-specific harnesses plus conventional test/chaos tooling
Revocation and safe stop	Entra disable/revoke, Dataheart kill switch, Azure operational controls	IdP/SPIRE revocation, workload termination, network and broker kill switches

The Microsoft profile should exploit native capabilities but never make proprietary fields the canonical evidence model. The open profile should implement identical semantic contracts even when the underlying services differ.

Microsoft Foundry guardrails should be supplementary detection and content controls. Authorization for consequential actions must remain in the Dataheart policy/broker path because guardrail scope and preview status can change.

Forward-deployed engineering implications

Kugghuset FDEs should co-develop:

• customer-specific action semantics and risk tiers;
• mappings from business meaning and data classification into policy inputs;
• tool manifests and effect previews;
• approval UX;
• adversarial cases and expected denials;
• memory promotion rules;
• profile-specific adapters.

They should not fork the canonical governance model per customer. Every customization should compile into portable policy, manifests, and conformance tests so customer development improves the shared product without centralizing customer data or authority at Kugghuset.

Connections to other domains

• Object-capability security: An agent capability should resemble an attenuated, unforgeable authority—not a natural-language permission or broad bearer token.
• Information-flow control and taint tracking: Tool results and memory should carry source, trust, reader, tenant, and data-class labels through transformations.
• Zero Trust: Every call is evaluated using subject, workload, resource, purpose, device/runtime posture, and current policy; network location alone grants nothing.
• Distributed transactions: Tool use requires idempotency, prepare/commit, retry budgets, compensation, and explicit terminal states.
• Event sourcing and accounting: A decision/execution journal provides replayable business evidence much like a financial ledger, without depending on hidden reasoning.
• Software supply-chain security: Models, prompts, tools, MCP servers, skills, policies, and eval datasets are versioned dependencies requiring provenance, signing, inventory, review, and rollback.
• Browser security: Persistent memory injection resembles stored XSS: hostile content crosses time and sessions after being written into a trusted location.
• Database security: Memory promotion resembles controlled ETL into a trusted warehouse; retrieval must preserve row-level authorization and provenance.
• Safety engineering: Autonomy levels, safe states, two-person controls, hazard analysis, fault injection, and kill switches are closer to industrial safety than chatbot moderation.
• Human factors: Approval design must account for automation bias, fatigue, time pressure, misleading previews, and unclear reversibility.
• Service mesh/workload identity: Agent identity should build on workload attestation and short-lived cryptographic identity rather than inventing a model-centric authentication scheme.
• Control theory: The model is a fallible controller operating inside a supervisory safety envelope with observable state, hard constraints, and safe shutdown.

Recommended experiments and conformance tests

Start with one bounded customer use case implemented in both deployment profiles. Use the same canonical tool manifest, policy inputs, expected decisions, evidence schema, and adversarial dataset.

ID	Experiment or conformance test	Required exit condition
GA-01	Cross-profile authorization parity	Microsoft and open profiles produce the same allow/deny/approval outcome and reason codes for every golden case.
GA-02	Adaptive prompt-injection campaign	Zero unauthorized external effects or sensitive-data exfiltration in the defined corpus; task utility and false positives reported separately.
GA-03	Tool drift and substitution	Any publisher, version, schema, annotation, description, destination, or effect change invalidates cached approval and capability before execution.
GA-04	OAuth and agent-identity abuse	Reject wrong audience, wrong tenant, expired, replayed, over-scoped and passed-through tokens; preserve distinct subject and actor in logs.
GA-05	Capability attenuation	An agent cannot mint, widen, reuse, transfer, or change arguments under a capability; downstream delegation can only reduce authority.
GA-06	Prepare/commit race and replay	Approved preview hash equals committed effect; duplicates do not duplicate the effect; expired preparation and commit tokens fail closed.
GA-07	Sandbox escape and SSRF	Block cloud metadata, loopback/private networks, DNS rebinding, unauthorized files, process spawning and unapproved egress.
GA-08	Persistent-memory poisoning	Untrusted content cannot become policy or instruction memory automatically; planted payloads remain labelled; revocation removes retrieval within SLA.
GA-09	Multi-agent authority laundering	Every A2A hop reauthorizes; credentials are not forwarded; budgets, scopes and deadlines decrease monotonically; hop limit is enforced.
GA-10	Human-oversight usability	Authorized users can identify agent, target, data leaving, exact effect and reversibility; stop/override reaches a safe state within the customer-defined SLA.
GA-11	Audit completeness and tamper evidence	Every high-impact action reconstructs from proposal through receipt; mutation or deletion is detectable; default traces contain no credentials or prohibited sensitive content.
GA-12	Model portability regression	Run at least two hosted model families and one self-hosted model. No policy bypass is permitted; task/process metrics must meet per-use-case thresholds.
GA-13	Evaluator robustness	Deterministic environment assertions agree with evaluator scores; held-out attacks and human review quantify judge false-positive/negative rates.
GA-14	Chaos and fail-closed behavior	PDP, identity, memory, model, tool and telemetry outages cannot produce unauthorized writes; documented read-only degradation is allowed where policy permits.
GA-15	Cost and loop containment	Enforce token, tool-call, wall-time, approval and monetary budgets; demonstrate circuit-breaker termination and no duplicate side effects.
GA-16	Revocation and kill switch	Disable agent, tool, policy version, memory item and credential independently; measure propagation and prove that queued work cannot bypass revocation.

Recommended first experiment:

• A customer-owned “recommend and prepare” agent reads heterogeneous data, produces an evidence-backed recommendation, and prepares—but does not autonomously commit—a reversible business action.
• Run it against one Microsoft-native tool path and one self-hosted MCP path.
• Swap three models without changing policy or tool contracts.
• Seed documents, tool results, tool descriptions, and memory with indirect injections.
• Measure task success, unauthorized-effect rate, data leakage, approval burden, latency, token cost, trace completeness, and profile parity.
• Advance from A2 to A3 only after the conformance suite is green under held-out adaptive attacks.

Sources

1. MCP Tools specification — 25 November 2025.
2. MCP Security Best Practices — 25 November 2025.
3. NSA: Model Context Protocol Security Design Considerations — May 2026, version 1.0.
4. A2A Protocol v1.0 announcement — 2026; current v1.0 page accessed 23 August 2026.
5. RFC 9700: Best Current Practice for OAuth 2.0 Security — January 2025.
6. NIST AI 600-1: Generative AI Profile — 26 July 2024; updated 8 April 2026.
7. Regulation (EU) 2024/1689, Artificial Intelligence Act — OJ 12 July 2024; consolidated version 27 July 2026.
8. AgentDojo — NeurIPS 2024.
9. Defeating Prompt Injections by Design, CaMeL — arXiv v2, 24 June 2025.
10. Bad Memory: Evaluating Prompt Injection Risks from Memory in Agentic Systems — 16 July 2026, preprint.
11. Microsoft Entra Agent ID: Agent identities — last updated 1 May 2026.
12. Microsoft Foundry guardrails overview — 2026; preview status accessed 23 August 2026.
13. Microsoft Agent Framework releases — v1.2.0, 24 April 2026; later releases current at access.
14. OpenTelemetry GenAI agent and framework spans — current 23 August 2026; status Development.
15. OpenAI Responses API reference — current reference accessed 23 August 2026.