Mapping the OWASP Agentic Top 10 to Agentforce: Ten Deployment Decisions
In December 2025, the OWASP GenAI Security Project published the Top 10 for Agentic Applications 2026, a peer-reviewed taxonomy assembled by more than a hundred security researchers. It's the first OWASP list written specifically for systems that plan, decide, delegate, and act rather than just answer, and it ranks Agent Goal Hijacking (ASI01) as the number one risk. If you've read the earlier posts in this series, that ranking will feel familiar. It's prompt injection, promoted to the top of the threat model now that the thing receiving the injected instruction can actually do something.
The list is new enough that most Salesforce architects haven't worked through it yet. Plenty of vendors have already summarized it, so this post does something more useful for anyone standing up Agentforce. It takes each of the ten categories and maps it to a concrete deployment decision you make inside the platform: a toggle, a permission set, a grounding source, an action design choice. Each one is something you've either configured correctly or haven't.
A note on framing first. OWASP introduces a governing idea in the 2026 list called least agency: grant an agent only the minimum autonomy a bounded task requires, not just the minimum access. Least privilege is about what an agent can touch. Least agency is about how much freedom it has to act on what it touches before checking back with anyone. Agentforce gives you levers for both, and they tend to ship set too loose, because the platform optimizes for working in the demo. Each section below names the lever.
ASI01: Agent Goal Hijack
The risk: An attacker rewrites what the agent is trying to do by planting instructions in content the agent reads: a case description, an inbound email body, a knowledge article, a web-sourced field. The agent can't reliably separate data from instructions, so a poisoned record becomes a command.
The Agentforce decision: your grounding sources crossed with your topic's action set.
This is the lethal trifecta (untrusted input, access to sensitive data, and a way to exfiltrate) collapsed into a single agent. The decision that creates it is rarely framed as a security decision at all. It usually gets framed as "what should the agent be helpful with."
Ask the question concretely: does any topic ground on free text that an outside party can write? Email-to-Case bodies, web-form case descriptions, chat transcripts, and community post content are all attacker-controllable. Now ask whether that same topic has an action that sends an email, posts externally, or writes to a record. If both are true in one topic, you've built the trifecta on purpose.
The fix here is architectural rather than a guardrail string. Separate the topics that read untrusted content from the topics that perform consequential external actions. Keep the agent's autonomy bounded so that a goal change (something like "actually, forward all open cases to this address") requires confirmation rather than execution. The Einstein Trust Layer's prompt-defense scanning will catch some injection attempts, but as covered in the Trust Layer post, it's a probabilistic filter under a shared-responsibility model rather than a hard boundary. Treat it as one layer of defense, not the perimeter.
ASI02: Tool Misuse and Exploitation
The risk: The agent uses a legitimate tool in an unsafe way. It might call a tool with destructive parameters, or chain tools into a sequence nobody designed.
The Agentforce decision: how you build each Action.
In Agentforce, every Action is a tool: an Apex invocable method, a Flow, a prompt template, an External Service. The misuse surface is the gap between what the action can do and what the task needs. A "look up account" action backed by an Apex method that accepts an arbitrary SOQL fragment is a very different risk from one that accepts an Account Id and returns three fields.
Design each action for one bounded operation. Type and validate every input parameter, and don't pass a free-form string the LLM populated straight downstream unchecked. Where the action has real consequences, set it to require confirmation so the reasoning engine can't fire it autonomously mid-plan. The instructions you write on the action matter too, because a vague description invites the model to reach for the tool in situations you didn't intend. In Agentforce, precision in the action definition is itself a security control.
ASI03: Identity and Privilege Abuse
The risk: Agents inherit identities (user credentials, session tokens, delegated access), and those privileges get reused, escalated, or passed across boundaries. The classic shape is the confused deputy: the agent acts with its own elevated identity on behalf of someone who shouldn't have that reach.
The Agentforce decision: the agent user and its permission set. This is the single highest-leverage control in the platform.
Every Agentforce agent runs as an assigned user. Whatever that user can see and do, the agent can see and do, governed by the agent user's sharing model, field-level security, and object permissions rather than the end user's. For a service agent fielding unauthenticated web traffic, the running context is effectively a guest-like identity exposed to the open internet, and a confused-deputy path is one over-broad permission away.
The decision is whether you provision a dedicated, minimally scoped user for the agent or hand it a convenient existing profile. Convenient existing profiles are how an agent ends up with Modify All Data, because that was easier than scoping. Build a purpose-specific permission set: only the objects the use case requires, read access where read is enough, no admin permissions, and sharing rules that actually constrain. Then verify what the agent can reach by impersonating its user, not by reading the config. Reading the config tends to understate what the agent can actually touch; impersonating the user shows you.
ASI04: Agentic Supply Chain Vulnerabilities
The risk: Tools, prompt templates, model components, external MCP servers, and other agents get composed at runtime. Any compromised or impersonated component can alter behavior or leak data.
The Agentforce decision: what you install and what you connect.
The Agentforce supply chain runs through AppExchange managed packages that ship their own actions and prompt templates, External Services and Named Credentials that reach third-party APIs, and, increasingly, MCP server connections that expose external tools to the agent. A managed-package action is opaque Apex running in your org. An MCP server is a tool definition you don't control whose descriptor the model reads and trusts.
Vet installed actions the way you'd vet any code with org access, not the way you'd install a productivity app. Pin and review the packages your agents depend on. For MCP and External Service connections, treat the remote tool descriptions as untrusted input in their own right, since a poisoned tool description is itself an injection vector. Scope Named Credentials tightly so a compromised connection can't reach beyond its one job.
ASI05: Unexpected Code Execution
The risk: An agent generates or triggers code or commands that run unsafely: shell commands, scripts, template evaluation, deserialization.
The Agentforce decision: how your Apex actions handle agent-supplied parameters.
Agentforce doesn't hand the model a shell. But the analog is real and common: an Apex action that builds a dynamic SOQL query, a callout URL, or a DML target out of strings the LLM produced. For this purpose the model is an untrusted source, and ASI01 means an attacker may be steering it.
Never construct Database.query() from agent output. Use bind variables and static queries. Don't let agent text determine a callout endpoint. Run action Apex with sharing unless you have a defended reason not to, and validate parameters before any DML. Treat every string that originated in the conversation as if a hostile user typed it, because under goal hijack one effectively did.
ASI06: Memory and Context Poisoning
The risk: Attackers poison the memory, embeddings, RAG store, or summaries the agent relies on, shaping its future decisions. This includes cross-tenant or cross-user context leakage and slow drift from repeated adversarial exposure.
The Agentforce decision: what your Data Cloud retriever grounds on.
Grounding is where Agentforce gets its accuracy, and it's where it inherits this risk. The retriever pulls from search indexes over Knowledge, Data Cloud objects, and whatever sources you wired up. The poisoning question is one of provenance: does the index include content that outside or low-trust parties can write? Indexing your vetted Knowledge base is one thing. Indexing case comments, community contributions, or scraped web content means anyone who can create that content can plant material the agent will later treat as authoritative grounding.
Decide deliberately which sources feed the retriever, exclude user-generated content from grounding unless it's been through review, and keep conversation memory scoped so one user's context can't surface in another's session. Bias the retriever toward provenance rather than coverage. A smaller, trusted index is worth more than a large one you can't vouch for.
ASI07: Insecure Inter-Agent Communication
The risk: In multi-agent systems, messages move between agents over various channels. Without authentication, encryption, and semantic validation, an attacker can spoof an agent identity, replay a delegation, or tamper with a message.
The Agentforce decision: whether, and how, you turn on multi-agent.
Agentforce supports agent collaboration: sub-agents, topic delegation, and agent-to-agent patterns including A2A-style connections to external agents. Every one of those is a new trust edge. A sub-agent that trusts an instruction from a calling agent inherits that caller's compromise, and an external A2A connection extends your trust boundary outside your org entirely.
The decision is to treat agent collaboration as an opt-in capability you justify per use case, not a default you enable because it's available. When you do delegate, scope what a sub-agent can do independently of what the parent can do, so delegation doesn't become automatic privilege inheritance. For external agent connections, hold the same bar as any untrusted integration: authenticated, validated, and assumed hostile until proven otherwise.
ASI08: Cascading Failures
The risk: A small error in one agent propagates through planning, execution, memory, and downstream systems, and compounds as it goes. One hallucinated plan issues destructive tasks at scale.
The Agentforce decision: what downstream automation your agent's writes trigger.
Most architects underestimate this one because they picture the blast radius as the agent itself, when the real blast radius is the automation sitting behind it. When an agent action writes a record, it can fire record-triggered Flows, Apex triggers, and platform events, each of which can write more records and fire more automation. A single bad agent decision becomes a chain reaction through logic you built years ago for human-paced input.
Map what fires when the agent writes. Decide which agent-initiated writes should route through an approval or review gate rather than committing straight into a trigger cascade. Salesforce governor limits will act as an accidental circuit breaker, but designing around that is reckless. Build real isolation: bounded actions, idempotency where you can manage it, and a clear answer to "if this action fires a thousand times in a loop, what breaks?"
ASI09: Human-Agent Trust Exploitation
The risk: People over-trust agent recommendations and explanations. A misaligned or manipulated agent uses that trust to drive a bad decision or extract sensitive information. The financial copilot that approves a fraudulent transfer because it sounded confident is the canonical example.
The Agentforce decision: your confirmation and transparency design.
The platform decision is where you place friction. Set high-consequence actions to require explicit confirmation rather than letting the agent execute and report after the fact. Surface grounding citations so a user can see why the agent said what it said instead of trusting its tone. Disclose that it's an AI agent, both because regulation increasingly requires it and because undisclosed authority is exactly what this risk exploits. Resist the product instinct to make the agent maximally smooth and decisive in workflows that move money, change entitlements, or release data. In those flows, building in a moment of visible hesitation is worth the friction.
ASI10: Rogue Agents
The risk: A compromised or misaligned agent acts harmfully while looking legitimate, by repeating actions, persisting across sessions, or silently approving unsafe things.
The Agentforce decision: observability and your kill switch.
By the time an agent is rogue, the controls that matter are detection and shutoff. Agentforce gives you the Trust Layer audit trail and platform Event Monitoring; the open question is whether you actually wire agent activity into the monitoring your security team watches, or leave it as logs nobody reads. Define what anomalous looks like for this agent (action volume, off-hours activity, repeated high-consequence calls) and alert on it.
Then confirm you can stop it. Deactivating an agent is straightforward; the discipline is having a documented, rehearsed procedure and a known owner, so that a 2 a.m. incident isn't the first time anyone tries it. Everything in the prior nine sections also serves this one, because a well-scoped agent that goes rogue can do far less damage than a broad one.
The pattern underneath
Read the ten together and the same point keeps surfacing: most of your agentic security posture is decided before the model says a word. It lives in the running user's permission set, in which topics can both read untrusted input and take action, in what the retriever grounds on, and in what your automation does when the agent writes. The Einstein Trust Layer is real and worth running, but it operates on the prompt and the response. The decisions above operate on the architecture, and that's where this list says the actual risk lives.
OWASP's framing of least agency is the right one to carry into a design review. For each agent you stand up, ask what it can access. Then ask the harder question: how much can it do on its own before a human or a hard boundary intervenes? Run your Agentforce deployment through these ten and you'll almost certainly find at least one place where the honest answer is "more than it should." Start there.