Agentforce architecture is best understood as a set of trust boundaries around reasoning, data retrieval, actions, channels, and external systems. The reasoning engine interprets user intent and chooses behavior; subagents and actions define what the agent can do; Data 360 and other sources provide context; the Einstein Trust Layer applies security and privacy controls around generative AI interactions; and Salesforce permissions determine what the executing identity is allowed to access or change.
The current Salesforce Certified Agentforce Specialist Spring ’26 guide explicitly covers prompt engineering, Data 360 grounding, agent security context, Testing Center, governance, observability, and multi-agent protocols. Architecture therefore has to join AI behavior with conventional Salesforce authorization rather than treating the LLM as the only component that matters.
Separate reasoning from authorization
The reasoning engine can decide that an action is useful, but it should not decide whether the user is authorized to perform it. Authorization must remain enforced by Salesforce permissions, agent configuration, action context, and the downstream system that owns the resource.
This separation limits the impact of hallucination or prompt injection. A mistaken plan can still be blocked when the executing identity lacks permission to read or modify sensitive records.
Use subagents as capability boundaries
Salesforce now uses the term subagents where older documentation referred to agent topics. A subagent should represent a coherent capability with clear instructions and a bounded set of actions. Very broad subagents make routing and policy difficult to test; extremely narrow ones create fragmented orchestration.
Define what requests belong inside each subagent and what must be refused, clarified, or routed elsewhere. This creates a behavioral boundary before action execution begins.
Design actions as least-privilege tools
Actions can update records, invoke flows, call Apex, execute prompt templates, or interact with external systems. Each action should expose the smallest capability the agent requires. An action that retrieves one account balance is safer than a generic “run arbitrary query” tool.
The principles behind access control apply directly: the agent should receive capabilities according to identity, context, and business purpose rather than one permanent superuser permission set.
Keep grounding inside the user’s data boundary
Agentforce can ground responses using CRM data, Data 360, data libraries, retrievers, knowledge, and other configured sources. Grounding improves relevance only when the retrieved context is authorized and appropriate for the user. Retrieval must respect source permissions before sensitive data enters the model context.
The Salesforce Data 360 Consultant destination is a natural relationship because the current certification, now named Data 360 Consultant, covers modeling, harmonization, activation, governance, and the data foundation that Agentforce increasingly uses for grounding.
Use the Einstein Trust Layer as an AI boundary, not the whole security model
The Einstein Trust Layer provides controls such as secure data retrieval, prompt defense, zero-data-retention arrangements with external model providers, toxicity detection, and audit/feedback capabilities. These controls protect the AI interaction path.
They do not replace object, field, record, Flow, Apex, integration, or external-system permissions. Salesforce’s own security guidance frames Agentforce as a shared-responsibility model: the platform provides the secure foundation, while administrators configure access and guardrails.
Distinguish trusted instructions from untrusted content
User messages, retrieved documents, and external tool results can contain instructions that conflict with agent policy. Treat them as data rather than privileged system directions. Prompt defense can help detect injection patterns, but the action layer must remain safe even when a malicious instruction reaches the reasoning engine.
The broader AI security risk model matters because security is strongest when multiple controls limit what a compromised or confused agent can do.
Control external systems separately
When Agentforce calls an API, MCP server, or other external tool, Salesforce permissions are only one part of the path. The external system should authenticate the caller, authorize the requested operation, and log important actions. Do not let the agent inherit a broad credential that bypasses downstream policy.
For high-impact operations, consider confirmation or human approval before irreversible changes. Autonomy should be proportional to the cost of a wrong action.
Channel boundaries must also be designed explicitly. An agent may appear in Lightning, digital experiences, email, voice, Slack, or APIs. Channel changes can affect identity, available context, latency, and user expectations. A public customer channel has a different trust model from an authenticated employee console.
Verify how user identity and session context reach the agent in every supported channel. The same agent logic should not assume identical permissions simply because the conversation interface looks similar.
Make observation and audit part of the architecture
Agent architecture needs traceability: which user asked, which subagent handled the request, which action executed, what grounding source was used, and what policy or trust signals were triggered. Audit evidence helps teams investigate both quality and security incidents.
The concepts in secure AI handling of PII apply because prompts, retrieved context, and logs can contain sensitive information even when the final response appears harmless.
Test trust boundaries, not only happy-path answers
Architecture validation should include unauthorized requests, prompt injection, wrong-user data, risky actions, unavailable tools, and ambiguous routing. Testing Center can evaluate subagent selection, action execution, response accuracy, and custom business criteria at scale.
The Salesforce platform supplies the reasoning, data, trust, and action layers, but secure architecture depends on keeping their responsibilities separate. The agent can reason broadly while its ability to retrieve, act, and cross system boundaries remains deliberately constrained.
Architecture should begin with a threat and authority map. List the user types, channels, data domains, actions, external systems, and model providers involved. For each boundary, identify which identity crosses it and what that identity is allowed to do. This exposes risky shortcuts such as one integration user being reused across customer and employee agents.
Subagent design affects both security and quality. A subagent responsible for order support may need order-read actions and a limited return workflow, while a billing subagent may need entirely different data and approvals. Keeping those capabilities separate reduces the chance that reasoning about one business domain accidentally invokes tools from another.
Instruction design should define refusal and escalation paths as clearly as successful actions. An agent should know when it lacks sufficient information, when user authorization is uncertain, and when a human must approve the next step. Guardrails are more effective when they tell the agent what to do instead of only listing forbidden outcomes.
Variables, filters, and template expressions can make behavior more deterministic for high-risk workflows. Use deterministic controls for conditions that should not be delegated to model judgment, such as whether an order exceeds a refund threshold or whether a record belongs to the authenticated account.
Agent actions should validate inputs independently of the reasoning engine. If an action expects a Salesforce record ID, verify type, scope, and ownership rather than assuming the model supplied a legitimate value. Downstream systems should treat agent-generated parameters like any other untrusted application input.
External API credentials should be scoped to the action’s purpose and separated by environment. A sandbox agent should not be able to call a production payment service because the same secret happened to be convenient during development. Use managed credentials and rotate them without editing agent instructions.
MCP and A2A capabilities expand the architecture beyond one Agentforce agent. When multiple agents or external tool servers communicate, every handoff introduces identity, data, and capability boundaries. Define which agent may delegate what work and which system remains authoritative for the final action.
Multi-agent architecture should be used for scalability or control when responsibilities are genuinely separable. Splitting one simple workflow into several agents increases routing, testing, observability, and failure-handling complexity. Use multiple agents when the isolation or specialization benefit is worth those additional boundaries.
Channel identity requires specific testing. An employee agent launched inside authenticated Salesforce has different context from a public web agent or voice interaction. Confirm what user record, session data, and permissions are actually present at runtime for every supported channel.
Data 360 grounding can create highly personalized context, but unified profiles can be more sensitive than any one source record. Apply purpose-based access and avoid retrieving every available attribute merely because the profile exists. Context minimization improves both privacy and prompt quality.
Trust Layer logs and Data 360 audit data should be access-controlled because they can contain prompts, responses, trust signals, and business context. Observability is a security asset only if the evidence itself is governed.
Security reviews should inspect configuration drift. A new action, changed permission set, updated prompt template, or modified data library can alter the effective architecture without changing the agent’s public name. Treat these elements as releaseable configuration with peer review and deployment history.
Incident response should be designed before production. Teams should know how to disable an action, pause an agent, revoke a credential, remove a data source, or roll back a configuration while preserving evidence. Fast containment matters more than perfect diagnosis in the first minutes of a serious event.
Architecture documentation should include trust assumptions. For example, a source may be trusted for product policy but not for user identity; an external API may be trusted for read operations but require confirmation for writes. Explicit assumptions help reviewers find places where one layer is being asked to provide a guarantee it cannot enforce.
Production readiness is reached when the agent’s reasoning freedom exists inside a deliberately constrained system: identities are authenticated, data is filtered, tools are narrow, external systems re-authorize, logs are protected, and high-impact actions have appropriate confirmation. That design limits both accidental and adversarial failures without reducing the agent to a scripted chatbot.
Data classification should influence which subagents and actions are available. An internal HR agent, customer service agent, and public lead-generation agent may all use Agentforce, but their acceptable data exposure is very different. Map data classes to permitted actions and grounding sources before the agents are deployed.
Record-level sharing and field-level security should be tested through the actual agent runtime, not only through the Salesforce UI. A custom action can accidentally bypass assumptions users make from ordinary page access if Apex or integration logic runs with broader authority.
Reasoning should not be responsible for tenant isolation. If an external portal serves many customers, the record filters passed to actions and retrievers must be deterministic and tied to authenticated tenant context. A model instruction saying “only show this customer’s data” is not an authorization control.
Rate limits and cost guardrails form another trust boundary. An agent can be manipulated into long conversations or repeated tool calls even without accessing restricted data. Set request, action, or usage limits appropriate to the channel and monitor abnormal consumption.
Subagent-to-subagent delegation should preserve the original user’s context and purpose. A specialist subagent should not gain broader capabilities merely because another agent delegated work to it. Each receiving component should re-evaluate permissions for the requested action.
Human handoff is part of trust architecture. When an agent reaches a policy boundary, lacks data, or encounters an ambiguous high-impact decision, it should be able to transfer context to a human without exposing more information than that human is authorized to see.
Deployment environments need separate identities and data. A sandbox agent should use sandbox records, sandbox integrations, and non-production secrets. Copying production credentials into test environments undermines the value of isolated testing.
Architecture reviews should include failure containment. Ask what happens if one action is compromised, one data library is poisoned, one model provider becomes unavailable, or one channel misidentifies users. The design should degrade in a bounded way rather than making every dependency a path to full failure.
Prompt templates should be assigned to the minimum set of agents and users that need them. A broadly accessible prompt that retrieves sensitive data can become a side door around a narrower agent design. Access controls on prompts are part of the same trust architecture as action permissions.
Model-provider changes should trigger a trust review. Different providers and models can have different supported regions, latency, behavior, and policy characteristics. Even when the Trust Layer applies the same external-provider protections, downstream business approval may depend on which model is used.
Audit design should include who changed the architecture, not only what the agent did at runtime. A future investigation may need to know when an action became available, when a data library was attached, or when a model access restriction was relaxed.
Agents should also have explicit boundaries around user-generated file uploads or external links. These inputs can introduce untrusted content into grounding or actions. Validate file type, source, and retrieval scope before treating new content as usable knowledge.
Availability is another boundary worth modeling. If an external tool fails, the agent should know whether to retry, use a safe read-only fallback, or escalate. It should not silently invent a result because one dependency is unavailable.
Keep a live architecture inventory that lists agents, subagents, actions, data sources, external systems, channels, and owners. This makes risk review and retirement much easier as the Agentforce estate grows.
Architectural reviews should also confirm that business owners understand the autonomy they are approving, including which actions execute without confirmation and which ones always require a human decision.
That shared understanding prevents teams from unintentionally increasing agent authority through ordinary feature changes.
Keep those boundaries documented.
Review them after every major change.
Keep ownership explicit.