Designing the Enterprise Agent Integration Layer: MCP, A2A and API Architecture

Created on 01 August 2026

Five key takeaways

Choose the protocol according to the boundary being connected: application-to-service, agent-to-tool, or agent-to-agent.
MCP and A2A are complementary. A common pattern is MCP inside an agent and A2A between independent agents.
Keep business invariants, authorisation and high-impact decisions in deterministic services and workflow controls; do not delegate them to model instructions.
Treat tool descriptions, Agent Cards, tool output and agent messages as untrusted input until validated, classified and policy-checked.
Evolve existing API management and integration platforms into a governed agent gateway, registry and observability plane rather than creating an unregulated parallel estate.

Introduction

Enterprise AI assistants can now retrieve information, call services, create records, start workflows and delegate work. Integration therefore becomes a runtime control problem, not only a developer concern.

Calling every new connection an “AI integration” creates confusion. Reading inventory, submitting a purchase order, receiving a shipment update, delegating contract review and waiting for approval are different interactions with different reliability, security and lifecycle requirements.

The Model Context Protocol (MCP) is designed primarily for an AI host or agent to discover and use tools, resources and prompts. The Agent2Agent (A2A) Protocol is designed for independent agents to discover capabilities, exchange messages and coordinate tasks. Traditional APIs, webhooks, event brokers, workflow engines and RPA remain important because they solve different problems. The architecture challenge is to compose them without allowing probabilistic model behaviour to bypass enterprise controls.

As of 1 August 2026, A2A has a released 1.0.0 specification, while MCP’s released specification is 2025-11-25 and a 28 July 2026 release candidate is available. The candidate is not a generally available production baseline; pin and test exact versions and implementations.

Business context and problem definition

Most enterprises already have APIs, middleware, event brokers, identity, data and workflow services. The gap is that this estate assumes deterministic applications, while agents introduce dynamic planning, natural-language inputs, long-running tasks and multiple execution paths.

Four problems recur:

Integration fragmentation. Each AI application can build its own connectors and credentials for the same CRM, ERP or knowledge repository, creating duplication and inconsistent security.

Unclear responsibility. A model may choose a tool, an agent may delegate, and a workflow may call a service. Without an explicit contract, accountability, identity, consent and policy become ambiguous.

Poor failure handling. A model response is not a durable transaction. Timeouts, duplicates, partial completion, approval and outages require state, retries, idempotency and compensation—integration and workflow concerns.

Expanded attack surface. Documents, tool descriptions and compromised servers can influence decisions or request excessive authority. A poorly designed proxy can become a confused deputy, so tool access increases the impact of prompt injection even when the API is secure.

The objective is composability without losing enterprise properties: identity, least privilege, policy enforcement, auditability, resilience, data protection and accountable ownership.

Core concepts and terminology

Name the boundary first to avoid protocol confusion.

Mechanism	Primary boundary	What it standardises	Typical enterprise use
REST or HTTP API	Application → service	HTTP resources, operations and security	Create an order or update a case
GraphQL	Application → data graph	Typed schema and client-selected query/mutation	Read related customer and order data
Webhook	Service → subscriber	Outbound callback and acknowledgement contract	Notify a payment or approval change
Event messaging	Producer → consumers	Async delivery, topics/queues and replay	Publish `OrderAccepted` to many consumers
MCP	Agent → tool, resource or context server	Discovery, session, structured calls and results	Search a repository or submit a bounded action
A2A	Independent agent → agent	Agent discovery, skills, tasks, artefacts and updates	Delegate a credit or engineering analysis
Workflow platform	Process → people, systems and agents	Durable state, timers, retries, compensation and approvals	Orchestrate onboarding over weeks
RPA	Worker → user interface	Screen and desktop/browser automation	Operate a legacy system without an API

API is application-to-service; MCP is agent-to-capability; A2A is independent-agent collaboration; workflow is process control; RPA is a fallback rather than a stable contract.

Discovery and capability declaration

Traditional APIs use an API description, catalogue or developer portal. OpenAPI describes HTTP APIs and OpenAPI 3.2 includes a webhooks field. GraphQL uses a typed schema and often supports introspection.

MCP clients negotiate capabilities and request a tool list. Each tool has a name, description and input schema; servers may provide an output schema in the MCP tools specification. This enables dynamic planning but makes metadata part of the model’s decision surface.

A2A uses an Agent Card describing skills, interfaces, modalities, capabilities and security. A public card can be discovered at a well-known URI; an extended card can be restricted to authenticated clients. A2A 1.0 also defines signed cards for metadata integrity.

Sessions, context and tasks

REST is often stateless; webhooks and events may be retried, so consumers need idempotency and deduplication. MCP 2025-11-25 has a stateful client-server session whose lifecycle negotiates version and capabilities. A2A is task-oriented: tasks have IDs, status, messages and artefacts and can be polled, streamed or pushed. This matters for work requiring minutes, input or recovery.

Protocol maturity at a glance

REST, GraphQL, webhooks, messaging, workflow and RPA are mature categories, though implementations vary. CloudEvents provides a CNCF event envelope and AsyncAPI 3.1.0 describes message APIs. A2A 1.0.0 is stable with a growing ecosystem; MCP remains useful but evolving, so the July 2026 candidate is emerging until selected as a baseline.

Architecture principles

Start with the business boundary. Decide whether the consumer needs a query, command, event, durable task or peer agent before choosing a protocol.
Keep the model outside the system of record. Services validate invariants, permissions, state transitions and transactions; the model may only plan or propose.
Use narrow capabilities. get_customer_balance with a constrained schema is easier to govern than run_sql or execute_shell. OWASP identifies excessive functionality, permissions and autonomy as causes of excessive agency.
Use async contracts for long-running work. Return a task ID, publish progress, support cancellation and define retries; do not hold a model request open for hours.
Make every boundary policy-enforceable. Authentication is not authorisation; a valid token does not grant every tool, tenant or action.
Treat language as untrusted input. Validate arguments, messages, outputs and generated content with normal application security controls.
Design for negotiation and failure. Pin protocol/schema/tool versions, reject unsupported capabilities and test compatibility; do not silently downgrade.
Propagate accountability, not secrets. Carry correlation, principal, purpose and policy context; never pass a bearer token without validating audience and authority.

Detailed reference architecture

This is a logical view, not a mandatory product topology; one platform may provide several boxes.

Users and channels

Channels include web/mobile, contact-centre, collaboration, API and scheduled clients. The channel authenticates the caller and shows proposed, pending and completed actions; a chat transcript is not a sufficient regulated audit record.

Agent host and application layer

The host controls model/task context, capabilities, approvals and the tool loop. It constrains tools, validates structured outputs and requires approval when policy demands it. Registration does not make metadata trustworthy.

AI integration gateway

The gateway evolves API-management and service-mesh controls. It routes MCP, A2A, REST, GraphQL and webhook traffic; enforces identity/policy, quotas and schemas; redacts data; adds correlation metadata; and emits telemetry.

A gateway enforces coarse policy and identity propagation; the business service still checks current state. Examples include Azure API Management exposing REST operations as MCP tools and importing A2A APIs, Apigee treating MCP as an API style, and AWS translating MCP requests to API Gateway REST targets. Treat previews as platform direction, not maturity evidence.

APIs, webhooks, events and queues

Use REST/GraphQL for synchronous owned operations, webhooks for callbacks, and queues/brokers for buffering, fan-out, replay and eventual consistency. Document events with AsyncAPI and, where appropriate, CloudEvents.

MCP servers and tool registry

An MCP server exposes focused tools, resources or prompts. The registry records owner, version, classification, consumers, security scheme, risk tier, health and deprecation date. Registration does not imply availability.

A2A agent endpoints

A2A endpoints expose an agent as a capability-bearing service. The caller discovers a card, authenticates, sends a task and receives a result, progress update or authorisation request. The remote agent owns its tools and should not receive the full conversation or unrestricted credentials.

Workflow platform and RPA

The workflow layer provides durable state, timers, retries, approvals, compensation and dashboards. Durable execution platforms persist progress through crashes and outages. An agent may propose a step, but the workflow owns transitions.

RPA sits behind a dedicated identity, isolated worker, screen-change monitoring and retirement plan: a tactical bridge while APIs are modernised.

Data, knowledge, identity and controls

Data and knowledge services include databases, documents, search, vector stores, master data and policy repositories. Apply source authorisation and minimisation before model access. Identity distinguishes human, workload, tool server, remote agent and downstream resource; policy considers action, resource, tenant, classification, purpose, risk, environment and approval.

Use private networking where required, egress restrictions, secrets management, isolation, sandboxing, key rotation, backup and recovery. External services are separate trust zones.

End-to-end process or data flow

The host first identifies the required capability and asks the gateway for an allowed route. A direct read may use MCP or an API. A long-running or cross-domain task may be delegated through A2A. The remote agent must make its own calls using its own approved tools and identity. Every hop should carry a trace and task correlation ID. Results are validated before being returned to the model or rendered to the user.

Protocol responsibilities: what must be designed explicitly

The protocol is only the transport contract; the enterprise still needs policy and operating ownership.

Concern	Practical design decision
Discovery	Use an approved catalogue; cache tool lists/cards with expiry and integrity checks; never discover arbitrary endpoints at runtime.
Capability declaration	Define purpose, side effects, schemas, classification, risk, owner and examples; treat descriptions as untrusted.
Authentication	Use enterprise identity, OAuth/OIDC, mTLS or workload identity; follow the OAuth 2.0 Security BCP and validate issuer/audience exactly.
Authorisation	Enforce scopes, resource permissions, tenant isolation, conditions and approvals in code and downstream systems.
Session management	Rotate/expire MCP sessions and bind them to the principal; separate A2A context, task and message IDs.
Context exchange	Pass minimum context in structured tenant, purpose, classification and correlation fields.
Error handling	Separate protocol, validation, business and transient errors; return machine-readable codes and safe messages.
Idempotency	Require command idempotency keys and deduplicate webhook/event consumers; retry only with a safe strategy.
Observability	Record protocol, route, tool/skill, principal, policy, latency, cost, outcome and trace/task IDs; redact content.
Versioning	Pin protocol, schema, tool and card versions; test negotiation and explicit unsupported-version responses.
Governance	Assign owner, approver, risk tier, support model, change process, retirement date and runbook.

MCP’s lifecycle requires version and capability negotiation. A2A 1.0 defines version headers, capability validation, task states and multiple delivery mechanisms. For HTTP APIs, use OpenAPI and RFC 9457 problem details. The goal is predictable errors, retries and ownership.

Security, privacy and governance considerations

An agent call is not a normal API call with a natural-language wrapper: data can influence the decision-maker. The goal is to limit consequences when a model, tool or peer agent is manipulated.

Key risks and controls

Risk	How it appears	Required control
Malicious tool descriptions	Misleading instructions or side-effect claims influence tool choice	Review/sign metadata; allowlist tools; validate schemas; separate descriptions from policy; adversarial-test selection
Prompt injection through tool output	A document, search result or API field redirects the agent	Mark external content as data; isolate it; validate outputs; limit tools; require approval for high-impact actions
Untrusted MCP/A2A server	A remote endpoint returns hostile content, changes capabilities or exfiltrates context	Use a trust registry, endpoint allowlist, TLS, signed metadata where available, sandboxing, egress controls and minimisation
Confused deputy	A proxy uses shared authority for the wrong caller	Bind consent to client and user; validate audience/issuer; preserve delegated identity; avoid shared high-privilege credentials
Excessive tool permissions	A read-only use case can write, delete or execute arbitrary commands	Expose narrow tools; use least-privilege identities; enforce policy downstream; rate-limit and gate approvals
Token passthrough	A proxy forwards a client token to the wrong downstream audience	Issue or exchange a target-specific token; validate audience, issuer and scopes; use mTLS or sender-constrained tokens where warranted
SSRF and unsafe discovery	Metadata or callback URLs target internal or cloud metadata addresses	Restrict schemes/destinations; use egress proxy; block private ranges; validate redirects; avoid open URL-fetch tools
Session hijacking and replay	A stolen session, task or webhook credential is reused	Short-lived bound credentials, rotation, signatures/nonces, replay detection and idempotent processing
RPA credential abuse	A desktop worker inherits broad user or administrator authority	Dedicated accounts, isolated hosts, vault-managed secrets, just-in-time access, recording and rapid disablement

The MCP security guidance covers confused deputy, token passthrough, SSRF, session hijacking, local compromise and scope minimisation. The NSA’s May 2026 guidance warns that unsafe implementations can turn attacker input into code-execution paths. Apply NIST’s zero-trust principle of per-request, least-privilege decisions and treat MCP servers as production integrations with supply-chain controls.

OWASP’s prompt-injection guidance recommends least privilege, output validation, approval and adversarial testing for indirect instructions. Its excessive-agency guidance adds downstream authorisation and minimised functionality, permissions and autonomy. These controls apply to A2A peers too.

For privacy, classify data before prompts, tool arguments, task history or telemetry. Define retention, location, access, deletion and vendor-training use. Redact secrets from traces but retain evidence for consequential actions. Map controls to existing ISMS, privacy, records, sector regulation and AI risk processes. ISO/IEC 42001 provides management-system structure and ISO/IEC 23894 risk guidance; neither makes a product compliant.

Architecture options and trade-offs

Option	Best fit	Strengths	Limitations and risks	Recommendation
REST/HTTP API	Stable service commands/queries	Mature contracts, tooling and gateways	No agent planning or task semantics	Default for system-to-system integration and system-of-record operations
GraphQL	Flexible typed reads	Precise fields and aggregation	Query cost, resolver security and mutation governance; not a task protocol	Use for governed read-heavy data composition
Webhook	Targeted notification	Simple and low latency	Retry, ordering, authentication and availability vary; not a workflow	Use for signed, replay-safe callbacks and status updates
Asynchronous messaging	Events, queues, fan-out	Decoupling, buffering, replay and scale	Eventual consistency and schema/operations complexity	Use for facts and work queues; document with AsyncAPI
MCP	Agent-to-tool/resource	Discovery, structured calls, results and session negotiation	Metadata is an attack surface; ecosystem and versions evolve	Use for narrow approved capabilities behind policy
A2A	Agent delegation/collaboration	Cards, skills, tasks, artefacts and async updates	Cross-agent trust, context leakage and task ownership	Use for an independent agent, not a function
Workflow platform	Durable process	State, timers, retries, approval, compensation and audit	Cost, modelling overhead and lock-in	Control high-value or long-running processes here
RPA	Legacy UI automation	Covers systems without usable APIs	Fragile selectors, credential risk and scaling limits	Use as a bounded bridge while modernising

A useful rule: API for application-to-service; MCP for agent-to-capability; A2A for an independent agent with its own task lifecycle; events/webhooks for notification; workflow for business state that must survive time and failure.

Build, buy or hybrid

Build business-specific tool or agent logic when it contains differentiated rules, private data access or controlled deployment requirements. Buy or reuse gateway, identity, broker, workflow, telemetry and protocol SDK capabilities. A hybrid usually works best: preserve APIs/workflows, add governed adapters and build domain policy/orchestration.

Evaluate interoperability, not a protocol checkbox: exact versions/bindings, auth flows, metadata controls, schema validation, retries, cancellation, audit export, residency, incident response, provenance, rate limits, tenancy and deprecation. Treat preview or experimental features as roadmap dependencies, not current capabilities.

Enterprise use cases

Financial services: commercial lending intake

Objective and architecture: reduce document-collection effort while retaining analyst approval and regulatory evidence. A lending API serves the customer application; an intake agent uses read-only MCP tools; a specialist analysis agent is delegated through A2A; and a workflow manages completeness, sanctions checks, review and submission. Events publish status changes.

Governance and result: no agent approves a loan or changes risk ratings. Case-scoped tools, minimised documents, source evidence, policy versions and human approval support faster preparation while keeping the decision in accountable services.

Government: permit and inspection coordination

Objective and architecture: help a resident understand a permit process and coordinate planning, environmental and inspection teams. A citizen-services API fronts the public channel; MCP provides approved policy and case lookups; A2A delegates specialist assessment; and a workflow schedules inspections, waits for documents and sends webhooks. The case system remains authoritative.

Governance and result: public content and uploads are untrusted, with privacy and records controls on every task. The agent labels indicative information, offers a human route and defers eligibility to the policy service, producing more consistent guidance without an opaque decision-maker.

Healthcare: referral and care coordination

Objective and architecture: reduce referral-routing delay and assemble a clinician-ready summary. Clinical APIs provide patient and appointment data; a purpose-limited, read-only MCP agent summarises it; an A2A specialist can return a structured work product; and a durable workflow manages consent, review, booking and notifications.

Governance and result: patient identity, consent, minimum necessary access, residency and clinical accountability are mandatory. Summaries remain drafts until clinician validation, reducing administration while preserving judgement and evidence.

Implementation roadmap

Phase	Main activities	Key artefacts and exit criteria
1. Discovery	Inventory APIs, events, webhooks, workflows, RPA, data, identities and candidate use cases	Capability map, trust boundaries, risks, owners and priorities
2. Design	Select boundaries; define tool/card contracts; design gateway, policy, identity, data and telemetry	Reference architecture, decisions, threat model, NFRs and approval model
3. Pilot	Test one read-heavy, reversible use case in a non-production zone, including injection, metadata, retry and leakage tests	Vertical slice, conformance tests, red-team results, runbook and baseline
4. Controlled rollout	Add bounded writes, workflow approvals, tenancy, capacity and selected partners	Readiness review, SLOs, support, audit evidence and rollback
5. Continuous improvement	Review usage, denials, incidents, changes, cost, latency and outcomes	Recertification, upgrades, deprecation, tests and maturity assessment

This lifecycle makes registration, review, controlled release and recertification explicit. Suggested artefacts: capability-to-protocol matrix; data-classification model; MCP/tool and Agent Card catalogues; API/event contracts; identity/token flows; policy table; threat model; retention schedule; dashboard; conformance tests; and decision records.

Organisational responsibilities

The product owner owns outcome and acceptable risk; the domain architect owns boundaries and system-of-record decisions; and the integration platform team owns gateway, event, workflow and protocol runtimes. Security and privacy approve trust zones, identity and data controls. Domain teams own API/tool/event correctness, AI engineering owns evaluations and model configuration, and operations owns SLOs, incidents, rotation and capacity. The Architecture Review Board approves exceptions, high-risk actions, cross-domain agents and external trust.

Non-functional requirements and measures

Define NFRs before choosing a product: gateway/workflow availability and recovery, tool/task latency, timeout and retry limits, duplicate-command tolerance, tenant isolation, residency, prompt/task retention, audit completeness, policy latency, call-rate limits, cost per outcome and approval response time.

Operational metrics include task completion, denied calls, invalid arguments, retry/duplicate rates, downstream errors, approval time, task age, A2A handoff success, MCP discovery failures, redactions, injection-test detection, cost per outcome and incidents by capability. Emit traces, metrics and logs using an OpenTelemetry strategy, and measure cycle time, rework, first-contact resolution or exception clearance—not only tokens and latency.

Common mistakes and anti-patterns

Using MCP as a universal API replacement. Preserve the ERP API for applications; add an MCP facade only when an agent needs a different interaction shape.

Using A2A for every function call. Its task and agent semantics are unnecessary for a local function or simple query.

Building a mega-agent. An agent with every tool, data source and permission is hard to test and contain. Prefer bounded agents and explicit orchestration.

Letting the model decide policy. Describe policy in prompts, but enforce authorisation in code and downstream systems.

Passing all context to every participant. Share only task-minimum fields; do not send unrelated records or reusable bearer tokens.

Ignoring asynchronous failure. Webhooks duplicate, events delay, agents stop and approvals take days. Define state, idempotency, cancellation and compensation before production.

Treating a registry as a trust decision. Discovery says what exists; it does not prove server safety or caller authorisation.

Allowing open-ended tools. run_shell, fetch_any_url, execute_sql and unrestricted files create large blast radii. Replace them with narrow tools or an isolated execution service.

Architecture decision checklist

Before approving an agent integration, the Architecture Review Board should ask:

What exact boundary are we connecting, and why is this protocol appropriate?
Is the capability a read, recommendation, reversible command, irreversible command or peer task?
What is the authoritative system of record and where are business invariants enforced?
What data crosses each trust boundary, and what is the minimum required context?
How are tools, skills, servers and Agent Cards discovered, approved, signed, versioned and retired?
Which identity represents the user, agent, tool server, remote agent and downstream service?
Can a compromised tool output cause an unauthorised action, data disclosure or prompt redirection?
What are the scopes, tenant boundaries, quotas, approval gates and emergency kill switches?
How are errors, timeouts, retries, duplicates, cancellation and partial completion handled?
Can operations reconstruct who requested what, which policy allowed it, which version ran and what changed?
Does the vendor support the exact protocol version and production status required, or is the feature preview?

Warning signs include no owner, API/identity inventory, classification process, rapid revocation, high-impact approval path or structured audit; shared administrator credentials; or “give the agent everything and add guardrails later.”

Conclusion

MCP, A2A, APIs, events, workflows and RPA represent different interaction models and trust boundaries: use APIs/GraphQL for application contracts, webhooks/messaging for notification, MCP for bounded agent capabilities, A2A for independent agent tasks, workflows for durable state, and RPA only as a short-term UI bridge.

The advantage comes from governing the capability catalogue, identities, policies, schemas, observability and operating responsibilities. An agent integration is enterprise integration with a probabilistic component; deterministic controls must keep it safe, explainable and recoverable when it is wrong.

Frequently asked questions

Is MCP a replacement for REST APIs?

No. MCP standardises how an AI host discovers and uses tools or resources; REST remains the normal application-to-service contract. An MCP server may wrap REST, but the API should remain independently governed.

Is A2A the same as an API?

A2A uses web-compatible endpoints, but its semantics are agent-oriented: Agent Cards, skills, messages, tasks, artefacts and async updates. Use an ordinary API for a deterministic operation; use A2A for an independent agent with its own task lifecycle.

Can prompt injection be solved by filtering tool output?

Filtering reduces risk but is not sufficient. Isolate external content, limit tools and permissions, validate arguments/results, enforce downstream authorisation, require approval for high-impact actions, rate-limit, monitor and adversarial-test.

When should a workflow platform be used instead of an agent?

Use a workflow platform for known steps, approvals, deadlines, durable state, evidence or compensation. An agent can classify, recommend or handle exceptions inside it; it should not replace explicit controls because a next step can be described in natural language.

Are MCP and A2A mature enough for production?

Both have production paths, but maturity is layered. A2A 1.0.0 is stable; MCP has a widely used release and a rapidly evolving ecosystem. Evaluate the exact SDK, gateway, server, binding, security model and support commitment. Pin versions, test interoperability and keep a rollback plan for experimental features.

References

Model Context Protocol Architecture, Model Context Protocol, 25 November 2025, modelcontextprotocol.io.
Model Context Protocol Lifecycle, Model Context Protocol, 25 November 2025, modelcontextprotocol.io.
Model Context Protocol Tools, Model Context Protocol, 25 November 2025, modelcontextprotocol.io.
Authorization, Model Context Protocol, 25 November 2025, modelcontextprotocol.io.
Security Best Practices, Model Context Protocol, 25 November 2025, modelcontextprotocol.io.
The 2026-07-28 MCP Specification Release Candidate, Model Context Protocol, 28 July 2026, modelcontextprotocol.io.
Agent2Agent (A2A) Protocol Specification, version 1.0.0, A2A Protocol community and Linux Foundation, 2026, a2a-protocol.org.
A2A Protocol Ships v1.0: Production-Ready Standard for Agent-to-Agent Communication, A2A Protocol community, 2026, a2a-protocol.org.
Google Cloud donates A2A to Linux Foundation, Google Developers Blog, 23 June 2025, developers.googleblog.com.
OpenAPI Specification v3.2.0, OpenAPI Initiative, September 2025, spec.openapis.org.
GraphQL, GraphQL Foundation, current documentation accessed 1 August 2026, graphql.org.
AsyncAPI Specification v3.1.0, AsyncAPI Initiative, 2025, asyncapi.com.
CloudEvents, Cloud Native Computing Foundation, graduated 25 January 2024, cloudevents.io.
OpenTelemetry Specification 1.59.0, OpenTelemetry community, 2026, opentelemetry.io.
RFC 9700: Best Current Practice for OAuth 2.0 Security, Internet Engineering Task Force, January 2025, datatracker.ietf.org.
RFC 9449: OAuth 2.0 Demonstrating Proof of Possession, Internet Engineering Task Force, September 2023, rfc-editor.org.
RFC 8693: OAuth 2.0 Token Exchange, Internet Engineering Task Force, January 2020, datatracker.ietf.org.
Zero Trust Architecture, NIST SP 800-207, National Institute of Standards and Technology, August 2020, nvlpubs.nist.gov.
Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, National Institute of Standards and Technology, 26 July 2024, nist.gov.
ISO/IEC 42001:2023 — Artificial intelligence — Management system, International Organization for Standardization, December 2023, iso.org.
ISO/IEC 23894:2023 — Artificial intelligence — Guidance on risk management, International Organization for Standardization, 2023, iso.org.
LLM01:2025 Prompt Injection, OWASP Gen AI Security Project, March 2025, genai.owasp.org.
LLM05:2025 Improper Output Handling, OWASP Gen AI Security Project, March 2025, genai.owasp.org.
LLM06:2025 Excessive Agency, OWASP Gen AI Security Project, March 2025, genai.owasp.org.
Agentic AI — Threats and Mitigations, OWASP Gen AI Security Project, 17 February 2025, genai.owasp.org.
Model Context Protocol: Security Design Considerations for AI-Driven Automation, National Security Agency, May 2026, nsa.gov.
Overview of MCP servers in Azure API Management, Microsoft Learn, 2025, learn.microsoft.com.
Expose REST API as MCP server, Microsoft Learn, 2026, learn.microsoft.com.
Import and manage A2A agent APIs in Azure API Management, Microsoft Learn, 2026, learn.microsoft.com.
MCP in Apigee overview, Google Cloud Documentation, 2026, cloud.google.com.
API Gateway REST API stages as targets for Amazon Bedrock AgentCore Gateway, Amazon Web Services, 2026, docs.aws.amazon.com.
Durable Functions overview, Microsoft Learn, 2 June 2026, learn.microsoft.com.
The definitive guide to Durable Execution, Temporal, 6 May 2025, temporal.io.
What is RPA?, Microsoft Power Automate, current documentation accessed 1 August 2026, microsoft.com.
RFC 9457: Problem Details for HTTP APIs, Internet Engineering Task Force, March 2023, rfc-editor.org.