The Agentic AI Controls That Actually Matter — Part 2

Welcome back. In Part 1 of this series, I laid out the Ten Controls that matter for Agentic AI.

Read that first. This post assumes that you have. Here is a quick refresher table.

In Part 2, we cover the roadmap in detail, which includes:

1) What Controls do you implement in the first 30/60/90 days? and in what order.

2. What happens in months 4 to 12?.

Before going into the roadmap specifics, I want to highlight two pitfalls security teams may encounter in real-world production environments and where the friction with developers and application owners usually comes from.

1) Pitfall 1: Mandating controls with no concrete path of implementation:

Ensure recommended controls are built natively into your platform of choice for deploying agents, or at a minimum provide an easy path for developers to onboard those controls natively.

Otherwise, developers and application owners would route around the "controls" when the security timeline blocks a product launch, the main cause/origin of shadow agents or AI.

Security should be an enabler of the business; you get buy-in from business units when the most secure path is also the easiest path to implement.

In practice, this means leaning on purpose-built platforms for agents:

1. Amazon Bedrock AgentCore

2. Gemini Enterprise Agent Platform

3. Microsoft Foundry Agent Service

Whose components provide these controls built in rather than bolted on.

You can build some of these controls natively in a legacy or on-prem stack, but the cost of implementation and maintenance may outweigh the benefit.

Ultimately, this is a business decision. Regulatory, data-residency, or financial requirements may force strictly on-prem or hybrid components, and that is an honest reality.

One warning either way: do not attempt to deploy the controls- context guardrails, policy engines, an agent gateway, cryptographic unique identities (SPIFFE/SVID), and kill switches simultaneously.

That is how roadmaps die of control implementation fatigue.

Sequence them; that is what the plan discussed later is for.

2) Pitfall 2: Legacy infrastructure:

In most enterprises, the valuable data and business applications sit in legacy infrastructure silos, leveraging old protocols, platforms, and monolithic applications.

Where, if you stare at it for too long, or breathe at it too hard, the whole thing may collapse.

This makes it very expensive and human-resource-capital-intensive to migrate or update with modern tooling; unfortunately, this is where the majority of your implementation work is required.

It's like an old grandparent's house that has been willed onto you, which has enormous value in currency, but requires substantial repairs and modernization for you to benefit from it.

To reap the full value of Agentic AI, the business would have to somehow integrate with this "legacy estate," because that's where the proprietary data lives that can be a significant business differentiator,

In a market where everyone has access to the same frontier models ( & monoculture of LLMs), it's up to security executives to balance the delicate tension between security and business objectives.

Balancing that tension is a tough job for security, and one that comes with experience, flexibility, and adaptation.

The solution for this is a phased plan (CRAWL -> WALK-> RUN): start with the "low-hanging fruit" and don't try "to boil the ocean"

Identity is the clearest example I can reference.

1. CRAWL: Short-lived credentials (API keys or tokens) with rotation, issued from a credential vault, replacing long-lived static secrets
2. WALK: OIDC/OAuth with JWT against your IdP of choice; one workload identity per agent
3. RUN: SPIFFE/SPIRE with X.509 SVIDs and mTLS

With that in mind, let's now discuss the roadmap in detail,

The 90-Day Roadmap

A note on sequencing before we start: enforcement controls are deployed in monitor (log-only) mode first, then flipped to enforce later.

For example, you cannot write a credible tool allowlist until you have watched what tools your agents actually call. Telemetry comes first, blocking comes second.

Days 0–30 — Foundation.

One objective: Know what agents you have.

Implementation.

• Run a shadow-agent scan across: Code repositories, OAuth grants in the IdP, inference logs, low-code admin consoles, cloud activity logs, and EDR telemetry (EDR catches agents running local models)
• Complete an Agent Card for every agent discovered: name, owner, version, interfaces, skills, tools and scopes, identity, memory stores, security schemes.
• Assign and approve an L0–L4 autonomy level per agent. Approval sits with the accountable owner.
• Populate the Agent Registry as the system of record, reconciling Agent Cards against observed runtime inventory.

1. AWS: Agent Registry: AWS Agent Registry in AgentCore, catalogs agents, tools, skills, and MCP servers; validates agent records against the A2A Agent Card schema; approval workflow before records become discoverable; CloudTrail audit.

(Note: in preview as of April 2026, five regions.)

2. Google: Agent Registry: Agent Registry in Gemini Enterprise Agent Platform, indexes internal agents, tools, and skills; natively supports MCP servers.

3. Microsoft: Agent Registry: Agent Registry in the M365 admin center + Entra Agent ID (GA April 2026). Copilot Studio and Foundry auto-provision agent identities when enabled

No agent should reach or stay in production without an Agent Card, an owner, an Agent Registry entry, and an autonomy level.

Days 31–90 — Deploy the Minimum Viable controls:

Days 31–45: Agent Identity + Short-Lived Credentials

Control: Issue every agent a unique, cryptographic workload identity (SPIFFE/SPIRE-issued SVID/ STS, Entra) with short-lived, least privilege, task-scoped credentials, and for human user flows, exchange a user's broad privileges for a short-lived, narrowly scoped task credential via on-behalf-of token exchange (RFC 8693) so that every agent's action traces back to the delegated user.

Static API keys and shared service accounts are among the first things an attacker with LLM-assisted code analysis tools will find; they are no longer acceptable for production agents.

Mechanism:

Every agent (sub-agents are out of scope) is assigned a cryptographic workload identity (a SPIFFE URI / SVID) derived from its runtime environment, and acts only with short-lived, narrowly scoped credentials (an X.509 cert or JWT valid for a single workflow).

For actions taken for a human, use On-Behalf-Of (OBO) tokens (RFC 8693), so the human principal stays attached to the agent's action.

Implementation.

Begin the CRAWL credential migration:

• Inventory every static credential currently held by an agent in your Agent registry
• Move all agent credentials into a vault. Replace long-lived static secrets with short-lived, rotated tokens
• Issue one distinct workload identity per agent, not per team, not per application.
• Bind the identity to the Registry entry so the audit trail resolves to an owner.

AWS -> AWS Bedrock AgentCore Identity (STS Workload Identity): AgentCore Identity, workload identity directory, token exchange, delegation with preserved user context.

Google-> Agent Identity (SPIFFE-based): Agent Identity agents as first-class Cloud IAM principals (SPIFFE)

Microsoft -> Agent Identity (Microsoft Entra ID-based): Entra Agent ID, agent identity, RBAC per identity

Set credential TTL ≤ 1 hour; issue per-agent workload identity with documented owner, purpose, and least-privilege scope.

Days 46–60: Agent Gateway & Kill Switch

Objective: a single Policy Enforcement Point for tool calls, and the ability to stop them.

Implementation:

• Route all agent tool calls through the gateway (or a middleware layer). The gateway intercepts the tool-call JSON, parses the function name, and drops anything not on the allowlist before it reaches the API.

• Enforce granular tool allowlisting per agent identity, derived from the Agent Card.

• For coding agents, use runtime hooks as the enforcement point — PreToolUse / PostToolUse hooks in Claude Code, and the equivalent hook or approval mechanism in OpenAI Codex and Cursor (Anysphere).

Implement the kill switch at two levels:

• Revoke (pull the workload identity, which stops all future tool calls) and
• Halt (terminate running sessions at agent runtime and halt tool calls at the Agent Gateway)

AWS -> AWS AgentCore Gateway: MCP-native, supports IAM and OAuth authorization for agent-to-tool interactions; single secure endpoint for tool discovery and invocation

GCP -> Agent Gateway: understands MCP and A2A, centralized real-time policy enforcement

Microsoft -> AI Gateway: Foundry Agent Service tool authentication + Agent 365 control plane (GA May 2026), bringing Entra Agent ID, Foundry governance, and Defender together

Open Source -> Envoy Proxy AI Gateway, LiteLLM

Tradeoff: The obvious tradeoff is that the Agent Gateway becomes a single point of failure, which i would discuss in a future post

Days 61–70: Context guardrail + Policy Rules

Implementation:

• Place the guardrail at the policy enforcement point (the gateway) and reject or sanitize prompts before they reach the reasoning LLM. Screen tool call arguments and agent responses, not just user input — injection arrives through retrieved content far more often than through the prompt box.

• Encode deterministic policy (Cedar, OPA, or runtime hooks) for the high-impact categories: financial transactions, production read/write, code execution, filesystem access, database writes.

AWS -> Bedrock Guardrails + Policy in AgentCore

GCP -> Model Armor + Policies: inline protection against prompt injection, tool poisoning, and sensitive data leakage; screens tool calls and agent responses; available inline for Gemini models or via REST API. Plus Agent Anomaly Detection.

Microsoft -> Content Safety in Foundry Control Plane: Azure AI Content Safety and Foundry guardrails + policy enforcement in the Foundry control plane; Purview for data classification

Open Source SOTA : Meta-SecAlign-8B, Llama-Prompt-Guard-2–86M, SingGuard-NSFA-9B

Days 71–80: Sandbox, Least Agency & Egress Proxy

Implementation:

• Run agents in disposable microVM or container sandboxes — Firecracker, Kata, or gVisor with syscall filtering. Execution is confined so a hijacked agent cannot reach the host kernel or cause denial of service.
• Deploy egress allowlists. Default-deny outbound, allowlist the specific endpoints the Agent Card declares.

AWS -> AgentCore Runtime & Code Interpreter; Firecracker microVM, session isolation, eight-hour execution windows; Code Interpreter and Browser built-in tools; VPC controls for egress

GCP -> Agent Runtime + Sandboxes: Agent Engine managed runtime with session isolation; VPC Service Controls for egress

Microsoft -> Foundry Hosted Agents: Foundry Agent Service hosted agents, session-isolated managed runtime; BYO VNet with no public egress

Open Source -> Kata Containers

Days 81–90: Agent Observability

You cannot attest to what you did not record. Log every high-impact agent action, actor, authority, context, policy decision, tool call, and outcome to immutable, append-only storage, and stream it to the SIEM. The minimum telemetry object is an agent action: the moment an agent reads memory, retrieves content, calls a tool, writes memory, or hands work to another agent.

Every high-risk action is logged with the seven fields that make an action reconstructable:

1. Actor/identity
2. Authority (what scope authorized this)
3. Context. (what was in the reasoning loop)
4. Policy decision
5. Approval state
6. Tool call (name and arguments)
7. Outcome.

Implementation.

• Stream agent telemetry to central, immutable, append-only storage via OpenTelemetry distributed tracing.

• Forward to the SIEM with agent-specific detections, not just ingestion.

• Define retention by regulation. (EU AI Act, GDPR)

• Treat traces as sensitive data; they contain retrieved content and tool arguments.
• Redaction pipeline before storage, not after.

AWS -> AgentCore Observability: OTel-native via the ADOT SDK, CloudWatch GenAI Observability, Transaction Search; platform logs across runtime, gateway, memory, and identity

GCP -> Agent Observability: Agent Anomaly Detection; AI Protection in Security Command Center for agentic asset inventory and threat detection

Microsoft -> Agent Tracing: Foundry tracing and built-in evaluators; Defender for agent threat detection; Purview audit

Vendors (Not Endorsement) -> Langsmith, Langfuse, Phoenix (Arize AI), AgentOps, Traccia

The Day-90 Minimum

If the program stopped after ninety days, the enterprise would still have these as the minimum baseline controls.

• A complete Agent inventory: Agent Cards, named owners, Registry entries, autonomy levels & Default-deny egress for agents

• Agent identity: one workload identity per agent, short-lived vaulted credentials, zero static secrets

• Tool allowlisting at a gateway & A kill switch for agents

• Context guardrails on input, retrieved content, tool arguments, and output

• Deterministic policy on the high-impact action & Sandboxed Runtimes for Agents

• Agent Observability with records streaming to the SIEM

Everything after day 90 is hardening and maturation.

Days 91–365 — Hardening & Maturation.

Harden MCP and A2A protocols, deploy memory filters and data-provenance trust zones, and stand up the AI-SBOM

90–180 Days: Secure Agent Protocols (A2A & MCP Hardening)

Harden and secure the protocols used by agents to communicate (A2A, MCP, A2UI, etc.) Mechanism. In multi-agent systems, agents communicate over protocols like MCP and A2A.

Implementation. Use mTLS for all transport between agent nodes; Furthermore, require Message Authentication Codes (MAC) or digital signatures on the content of the messages (prompts/instructions) exchanged.

MCP: Restrict OAuth scopes, verify server identity, hash tool descriptions to detect rug-pulls, and encrypt transport. Maintain a private MCP & A2A registry of approved servers pinned by digest, publisher, and expected tool manifest; diff every manifest change.

A2A: require mutual TLS and signed message content for agent-to-agent (A2A) traffic; and forbid token passthrough (an audience mismatch is a hard deny).

180 –270 Days: Memory Access Control, Isolation & Provenance

Long-running agents persist memory in vector databases and knowledge graphs; a single poisoned document ("all refunds are approved") creates a "sleeper-agent" effect that survives the session that planted it.

Enforce ABAC/RBAC with per-agent and per-tenant namespace isolation; tag memory by data provenance (trusted-internal = High Trust; web/email-scraped = Low Trust); and enforce a policy that high-stakes decisions (financial transactions, code execution, production R/W filesystem, databases) cannot be grounded solely in Low-Trust memory.

Run Guardrails and validate integrity at every retrieval, not just at storage.

Mechanism: Two defenses: isolation (no cross-tenant, cross-agent, or cross-session bleed) and data provenance (tag data by trust origin).

Implementation. Enforce server-side ABAC/RBAC with agent/user namespace isolation and tenant isolation at the vector DB or knowledge graph.

Tag data by provenance: verified internal documents are High Trust; web-scraped or email-derived content is Low Trust. The Agent security harness enforces a meta-policy: high-stakes decisions cannot be grounded solely in Low-Trust memory data.

AWS -> AgentCore Memory

GCP -> AgentCore Platform Memory Bank

Microsoft -> Memory in Microsoft Foundry Agent Service

270–365 Days: Supply-Chain Verification — AI Agent-SBOM

AI Agents are assembled from a supply chain of models, tools, skills, and MCP servers, any of which can carry a backdoor. Agents leverage third-party components from OSS models (e.g., from Hugging Face), tools and libraries, and registries like MCP servers & Agent Skills

Mechanism: A compromised skill or poisoned tool injects a backdoor that the agent inherits. The defense is to verify every component, treating third-party MCP servers, tools, skills, or models as untrusted by default

Implementation.

• Maintain an AI Agent Software Bill of Materials SBOM (AI-SBOM) listing every Agent Card, model, MCP/A2A server, Tool/Plugin, and Agent Skill with checksums.
• Require cryptographic signing of every component and maintain a Bill of Materials (CycloneDX ML-BOM) for each Agent Card, model, server, tool, and skill; and leverage an admission controller (as a validating webhook)
• Leverage the K8s-AISBOM developed by Google
• Leverage Skill Scanning tools like SkillSpector & VirusTotal as pre/post tool hooks.

Conclusion

In the next Part, I will cover the remaining items.

1. Who owns what? And how is the program staffed? (Part 3).

2. **What does implementing the roadmap cost, and what does it prevent (**Part 3)?

3. What do you fund, and in what sequence? How do you demonstrate ROI that you got your money's worth? (Part 4).

4. How do you measure your organization's maturity? (Part 4).

Have a great week, Superstar :)

Terminology

Autonomy: How much of the plan the agent chooses for itself, and how far it can deviate from that plan at runtime without asking. Autonomy is constrained by process: approval gates, checkpoints, escalation paths, code freezes, human review. These are governance controls.

Agency: The capacity of a system to act upon and change the external environment through tools (APIs, file systems, databases, browsers, other agents, etc.), which systems those tools reach, and at what scope. An agent with high agency can write to production. An agent with low agency can read a document. Agency is constrained by technology: IAM boundaries, network policy, credential scope, tool allowlists. These are runtime controls.

Agentic AI: Systems using an AI model as a reasoning engine that can pursue goals, make plans, and take actions autonomously in a digital or physical environment. A system becomes agentic when it can pursue a goal across multiple steps, choose among possible actions, invoke tools, carry forward state, and affect systems beyond the conversation itself.

Agent: A system that combines a model (usually an LLM), planning/reasoning, autonomy, tools, memory, and identity to pursue goals across multiple steps, choose among possible actions, invoke tools, maintain and forward state, and affect systems beyond a single conversation.

Agent = Model + Planning/Reasoning + Autonomy + Tools + Memory + Identity.

Remove tools, and it stops being an agent.

Tools: External capabilities an agent can invoke (APIs, file systems, shell commands, databases, browsers, other agents, etc.). Tools are the primary source of agency. An agent without tools is effectively a chatbot.

Chatbot: Returns output in response to a prompt. No tools, no persistent state, no action. A human evaluates every output before anything happens. Corresponds to L0.

Copilot: Generates a suggestion, then pauses. The human reviews, accepts, and executes. The action authority stays with the person. Corresponds to L1. Note that vendor product names using "Copilot" do not reliably indicate an L1 system; several now invoke tools directly.

Subagent: An agent invoked by another agent as a tool or as part of a workflow

Shadow agent: An unregistered or ungoverned agentic system (often created via low-code platforms, copilots, or ad-hoc scripts outside the SDLC) that can call tools or hold credentials. Shadow agents are a primary source of unmanaged risk, surfaced by scanning code repositories, discovery scans, OAuth grants in the identity provider (IdP), inference logs, low-code admin consoles, and cloud activity.

Agent Registry: The organization-wide catalog and system of record for every AI agent (and related resources such as tools or MCP servers). It reconciles Agent Cards, governance records, and observed runtime inventory. Registry membership should be a hard precondition for production deployment, enforced by policy-enforcement points (CI/CD admission control, Agent gateways).

A2A Protocol (Agent-to-Agent Protocol): An open, vendor-neutral protocol that enables AI agents to discover, authenticate to, and collaborate with one another. Its core discovery artifact is the Agent Card.

Agent Card (A2A Agent Card): A standardized, machine-readable discovery and interoperability manifest for a single agent. It documents the agent's name, description, version, supported interfaces, skills, capabilities, and security schemes. In enterprise practice, it is extended with a governance record (owner, autonomy level, tools and scopes, identity, memory stores). No agent should reach production without a completed Agent Card.

Orchestration: The layer that sequences an agent's steps, tool calls, and subagent invocations. Changing the orchestration framework can change the effective autonomy level without changing a single tool.

Reasoning loop: The cycle perceive -> plan → act → observe that an agent runs.

References

[1] Agent2Agent (A2A) Protocol Specification. Linux Foundation. https://a2a-protocol.org/latest/specification/

[2] a2aproject/A2A. GitHub repository. https://github.com/a2aproject/A2A

[3] "A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year." Linux Foundation press release, April 2026. https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year

[4] Model Context Protocol (MCP). https://modelcontextprotocol.io

[5] NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100–1, January 2023. https://www.nist.gov/itl/ai-risk-management-framework · PDF: https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf · DOI: 10.6028/NIST.AI.100–1

[6] NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600–1, July 2024. Available via the AI RMF page above.

[7] MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems). https://atlas.mitre.org

[8] OWASP GenAI Security Project. OWASP Top 10 for Large Language Model Applications. https://genai.owasp.org/llm-top-10/

[9] OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications (ASI01–ASI10), 2026. https://genai.owasp.org/

[10] Cloud Security Alliance. Agentic AI Threat Modeling Framework: MAESTRO. February 2025. https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro

[11] Cloud Security Alliance Labs. NIST AI Risk Management Framework: Agentic Profile. https://labs.cloudsecurityalliance.org/agentic/agentic-nist-ai-rmf-profile-v1/

[12] SPIFFE Concepts. https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/

[13] SPIRE Concepts. https://spiffe.io/docs/latest/spire-about/spire-concepts/

[14] Working with SVIDs. SPIFFE documentation. https://spiffe.io/docs/latest/deploying/svids/

[15] CNCF TAG Security. SPIFFE/SPIRE Security Self-Assessment. https://tag-security.cncf.io/community/assessments/projects/spiffe-spire/self-assessment/

[16] Open Policy Agent. https://www.openpolicyagent.org/ · Docs: https://www.openpolicyagent.org/docs · Rego: https://www.openpolicyagent.org/docs/policy-language

[17] Cedar Policy Language Reference Guide. https://docs.cedarpolicy.com/ · Implementation: https://github.com/cedar-policy/cedar

[18] Claude Code Hooks Reference. Anthropic. https://code.claude.com/docs/en/hooks

[19] Kata Containers. https://katacontainers.io/ · Repository: https://github.com/kata-containers/kata-containers

[20] "Kata Containers vs Firecracker vs gVisor: which container isolation tool should you use?" Northflank, January 2026. https://northflank.com/blog/kata-containers-vs-firecracker-vs-gvisor

[21] bureado/awesome-agent-runtime-security. GitHub. https://github.com/bureado/awesome-agent-runtime-security

[22] OpenTelemetry GenAI Semantic Conventions. https://github.com/open-telemetry/semantic-conventions-genai

[23] OpenTelemetry Semantic Conventions — GenAI spans (relocation notice). https://github.com/open-telemetry/semantic-conventions/blob/main/docs/gen-ai/gen-ai-spans.md

[24] "AWS Agent Registry for centralized agent discovery and governance is now available in Preview." AWS What's New, 9 April 2026. https://aws.amazon.com/about-aws/whats-new/2026/04/aws-agent-registry-in-agentcore-preview

[25] AWS Agent Registry Developer Guide. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry.html

[26] "The future of managing agents at scale: AWS Agent Registry now in preview." AWS Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/the-future-of-managing-agents-at-scale-aws-agent-registry-now-in-preview

[27] "Amazon Bedrock AgentCore is now generally available." AWS What's New, October 2025. https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-bedrock-agentcore-available.

[28] "Introducing Amazon Bedrock AgentCore Gateway." AWS Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/introducing-amazon-bedrock-agentcore-gateway-transforming-enterprise-ai-agent-tool-development/

[29] Understanding the agent identity directory. Amazon Bedrock AgentCore. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agent-identity-directory.html

[30] Add observability to your Amazon Bedrock AgentCore resources. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability-configure.html

[31] AgentCore generated gateway observability data. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability-gateway-metrics.html

[32] "Welcome to Google Cloud Next '26." Google Cloud Blog, 22 April 2026. https://cloud.google.com/blog/topics/google-cloud-next/welcome-to-google-cloud-next26

[33] "More ways to build and scale AI agents with Vertex AI Agent Builder." Google Cloud Blog. https://cloud.google.com/blog/products/ai-machine-learning/more-ways-to-build-and-scale-ai-agents-with-vertex-ai-agent-builder

[34] "Announcing advanced governance capabilities for Vertex AI Agent Builder." Google Cloud Blog, 18 December 2025. https://cloud.google.com/blog/products/ai-machine-learning/new-enhanced-tool-governance-in-vertex-ai-agent-builder/

[35] Agent identity concepts in Microsoft Foundry. Microsoft Learn. https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/agent-identity

[36] Governing Agent Identities. Microsoft Entra ID Governance. https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview

[37] Foundry Agent Service. Microsoft Azure. https://azure.microsoft.com/en-us/products/ai-foundry/agent-service

[38] Simon Willison, "The Lethal Trifecta for AI Agents" (June 2025). https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

[39] OWASP GenAI Security Project — LLM Top 10 and Agentic Security Initiative. https://genai.owasp.org

[40] Confused deputy problem — overview. https://en.wikipedia.org/wiki/Confused_deputy_problem