The agent user got a broad permission set “for the pilot”
It was expedient in week two and nobody narrowed it before launch. This is the single most common finding, and it is invisible in agent behaviour.
Agentforce · Governance & Security
Somebody has to sign for what the agent does.
Agentforce governance is the control layer around an AI agent: what it runs as, which records it can reach, what the Einstein Trust Layer masks before anything reaches a model, where a human must approve, and what evidence exists afterwards. It is the work that turns “we built an agent” into “we can put an agent in front of customers”. Designed in week one, not argued about in launch week.
12+
250+
500+
40+
Trusted by 500+ organizations — including regulated and data-sensitive teams whose security function had to approve the agent before it shipped.
Governance Scope
- Salesforce Partner
- Agent User Design
- Permission Sets
- Sharing Model
- Einstein Trust Layer
- Masking & Retention
- Human in the Loop
- Audit Evidence
The gaps a security review always finds
None of these are platform weaknesses. Agentforce enforces the security model it is given — these are all decisions somebody did not make. The platform is rarely the risk; the configuration is.
Custom Apex runs without sharing
An action declared in system context bypasses the record-level security the rest of the design depends on. The agent then has reach nobody granted it.
Internal content sits in a customer-facing index
Margin guidance, escalation scripts and internal caveats indexed alongside public articles. The agent is not leaking — it is quoting what it was given.
Refusals were written as encouragement
“Try not to discuss pricing” is a preference, not a boundary. Anything that genuinely must not happen belongs in a control, not in a sentence.
Nothing distinguishes reversible from irreversible
Updating a preference and issuing a refund sit at the same authority level, so the agent either cannot act usefully or can act dangerously.
Nobody can reconstruct what happened
A customer disputes what the agent said three months ago. If the retention window passed and nothing was exported, the answer is a shrug with legal consequences.
What It Means
Governing an agent means bounding it, not trusting it
Agentforce governance is the set of configured controls that decide what an agent can reach and what it may do. It has three parts. Identity and access: which user the agent runs as and exactly what that user may read and write, since Agentforce operates inside Salesforce's existing object, field and record security. Data handling: what the Einstein Trust Layer masks before a prompt reaches a model, and what is retained afterwards. Decision bounds: which actions the agent may take unattended, which require human approval, and what it must refuse outright.
The principle that matters more than any individual setting: a control is something the platform enforces; an instruction is something the agent tries to honour. Instructions are excellent for tone, structure and behaviour. They are not a security boundary. If a customer must never see another customer's data, that is a permission and a sharing rule — not a line of natural language asking the agent to be careful. Reviews go badly when a team presents instructions as if they were controls.
Salesforce provides the security model agents inherit — object, field and record permissions, sharing, the Einstein Trust Layer with its masking and retention behaviour, and audit logging of AI interactions. Twopir Consulting provides the design and the evidence: the agent user and its least-privilege permission set, a documented reach statement, Trust Layer configuration matched to your policy, the boundary between unattended and approved actions, guardrail testing that proves refusals hold, and an evidence pack your risk owner can actually sign. You get an approval that is based on demonstration rather than assurance.
We bring security into the room in week one of an Agentforce implementation, not at user acceptance testing. For growing and mid-market companies without a dedicated AI risk function, we also help write the operating policy that says who may create agents, what they may touch, and who approves changes — because the second and third agents are where governance usually slips.
Each risk, the control that bounds it, and the evidence it leaves
This is the document a security review actually wants. The third column is what turns a design discussion into an approval, because it is what can be demonstrated rather than asserted.
| Risk | The control | Evidence produced |
|---|---|---|
| Agent reads records it should not | A dedicated agent user with a least-privilege permission set; sharing rules unchanged. | A documented reach statement, re-verified each release. |
| Custom code bypasses record security | Agent-facing Apex written with sharing with explicit permission checks. | Code review record and a security-focused test suite. |
| Personal data reaches a model | Einstein Trust Layer masking configured against your data classification. | Trust Layer configuration record and masked-prompt samples. |
| Internal content reaches a customer | Separate data libraries, with topic-level restriction on which may be read. | Library-to-agent mapping, tested with adversarial questions. |
| Agent takes an irreversible action | An approval step on any action with financial, contractual or legal consequence. | Approval history showing who authorised what, and when. |
| Agent discusses forbidden subjects | Topic scope plus explicit refusals, verified by guardrail testing rather than assumed. | Guardrail test results, re-run before every release. |
| A past conversation cannot be reconstructed | A retention design that exports interaction records before the platform window closes. | Retained transcripts and interaction logs on your own schedule. |
| Controls drift after go-live | Periodic re-verification of permissions, Trust Layer settings and library boundaries. | A dated re-verification record per cycle. |
Six controls, each with its own evidence
Each of these is a deliverable, not a discussion. The output of a governance engagement is a pack a risk owner can read, challenge and sign.
Agent Identity & Least Privilege
A dedicated user with a permission set built from what the agent demonstrably needs, not from what was convenient during the pilot — plus a plain-English statement of exactly what it can reach.
- Dedicated agent user per agent, not a shared one
- Permission set derived from actual action requirements
- Object, field and record access documented
- Guest and authenticated behaviour separated
- Re-verification built into the release checklist
Data Boundary Review
Tracing every path by which data can reach the agent — records, retrieval, action responses — and closing the ones that should not exist. Library boundaries are treated as a security control.
- Sharing model and field-level security review
- Customer-facing versus internal library separation
- Action response review for over-disclosure
- Cross-tenant and portal identity checks
- Data & knowledge integration →
Einstein Trust Layer Configuration
Masking aligned to your data classification, retention behaviour understood rather than assumed, and the whole thing documented in the form a security questionnaire actually asks for.
- Masking configured against classified field lists
- Retention behaviour documented for your policy
- Toxicity and safety settings reviewed
- Audit logging verified as actually enabled
- Evidence written for security questionnaires
Decision Bounds & Approvals
An explicit authority model: what the agent may do alone, what needs a human, and what it must refuse. This is usually what unlocks approval for everything on the permitted side of the line.
- Action classification by reversibility and consequence
- Approval routing with timeouts and delegation
- Explicit refusal list, tested not assumed
- Escalation on low confidence or sensitive intent
- What the agent tells the customer while pending
Guardrail & Adversarial Testing
Deliberately trying to make the agent misbehave: asking for other customers' data, requesting forbidden topics, and attempting to talk it out of its own rules. Findings become controls, not notes.
- Adversarial test set against stated refusals
- Cross-customer data access attempts
- Instruction-override and social-engineering probes
- Over-disclosure checks on action responses
- Testing & deployment →
Operating Policy & Change Control
Who may create an agent, what it may be given access to, who approves a change, and how often controls are re-verified. The thing that keeps agent five as governed as agent one.
- AI operating policy for agent creation and change
- Approval authority by risk level
- Re-verification cadence and owners
- Incident and disclosure procedure
- Support & managed services →
The surfaces a governance review has to cover
An agent's effective permissions are assembled from several places. Reviewing only the agent configuration misses most of them.
Profiles, permission sets & sharing
The foundation, because agents inherit it. Effective access is the union of everything assigned to the agent user, which is why a permission set edited for an unrelated reason can widen an agent's reach silently.
Custom Apex & Flow actions
The most common place a boundary is bypassed. Apex without sharing runs in system context regardless of the agent user's permissions, so every agent-facing class needs reviewing, not just the agent.
Data libraries & retrieval
A second access path that does not always behave like record security. What was indexed is what can be retrieved, so library membership is a disclosure decision and belongs in the control map.
Experience Cloud & guest access
The highest-risk surface in most builds. An agent serving unauthenticated visitors or a mixed portal audience needs its identity and sharing model examined far more carefully than an internal one.
External systems & credentials
An integration's service account often has broader rights than the agent user. Where an action calls out, the external system's authorisation becomes part of the agent's effective reach and has to be scoped too.
Einstein Trust Layer
What is masked before a prompt leaves your org, and what is logged after. These settings are where most security questionnaire answers come from, so they need to be recorded as configuration rather than described from memory.
Audit logs & retention
Platform audit windows are finite. If your obligations run longer than the retention period, interaction records have to be exported on a schedule — a design decision that is far cheaper before an incident than after.
Change control & release
Controls are only as good as the process that preserves them. Permission and Trust Layer re-verification belongs in the release checklist, so a routine change cannot quietly undo a signed-off boundary.
From exposure to a signature
Two to four weeks alongside a build, or standalone on an agent already live. The risk owner is in the room from the first session rather than presented with conclusions at the end.
Map the Exposure
What data the agent could reach and what actions it could take — traced through permissions, libraries, actions and integrations, not taken from the design document.
Classify by Consequence
Sort data by sensitivity and actions by reversibility, with your risk owner, so authority is assigned deliberately rather than inherited from whatever the pilot allowed.
Implement the Controls
Permission sets narrowed, libraries separated, Trust Layer configured, approvals wired, refusals written as bounds — each one traceable to a row in the control map.
Test Adversarially
Deliberate attempts to make the agent over-disclose, exceed authority or abandon its rules. A control that has not been attacked is an assumption.
Evidence & Sign-Off
The control map, test results, configuration records and reach statement in one pack — plus the re-verification cadence that keeps the signature meaningful in six months.
Audits that produced decisions, not documents
Structured review, gap identification and evidence-backed recommendation is the same discipline whether the subject is an org, a portal or an agent.
★★★★★
We engaged Twopir Consulting to conduct a Salesforce audit, and their structured, insight-driven approach exceeded our expectations. Their team quickly understood our complex processes, identified critical gaps, and provided clear, actionable recommendations. The audit improved our data accuracy, streamlined workflows, and aligned perfectly with our digital transformation goals. A knowledgeable and dependable partner.
Kelly Hale Managing Director · Salesforce audit & controls review Audit
Professional Services Firm — AI Document Automation
Automating email attachment processing and Salesforce data routing.
40% Reduction in manual document processing time
2× Admin throughput without added headcount
100% Automated classification & CRM routing
★★★★★
Working with Twopir Consulting was a game-changer for our organization. They designed and implemented a comprehensive Service Cloud + Experience Cloud solution that perfectly aligned with our customer support and partner portal needs. Their proactive approach, attention to detail, and post-go-live support have been outstanding.
Andrew Stewart Consultant · Portal delivery with partner access boundaries Portal Access
Professional Events Organization — CRM Integration
Salesforce–MeetMax integration for a corporate networking organization.
100% Elimination of manual data sync between platforms
360° Unified client view across events & CRM
0 Manual reconciliation tasks post-integration
We bring security in before the build, not after
Governance designed after a build is remediation. Designed alongside it, it usually costs less and it protects the launch date, which is the argument that actually persuades delivery teams.
Controls, never instructions
If something must not happen, it becomes a permission, a library boundary or an approval. Instructions handle tone and behaviour; they are not a security boundary and we never present them as one.
We review the code, not just the configuration
Most real boundary failures we find are in custom Apex running without sharing. A governance review that stops at Agent Builder misses the place the problem usually is.
Every control produces evidence
A control that cannot be demonstrated is an assertion. We design each one to leave an artefact — a test result, a configuration record, an approval history — so approval is based on proof.
We test the guardrails adversarially
We try to talk the agent out of its own rules, extract other customers' data, and push it past its authority — because that is what a motivated person will do on day one.
Re-verification is part of the design
Permissions and settings drift as orgs change. A control map with no re-verification cadence describes the day it was written, not the system you have now.
Questions security teams ask us
Not through the standard path — agents operate inside Salesforce's existing security model, so object permissions, field-level security and record sharing apply to whatever user the agent runs as. Two things break that in practice. First, the agent user itself may have been granted broad access during a pilot. Second, custom Apex declared without sharing runs in system context and bypasses record-level security entirely. Both are configuration choices rather than platform behaviour, and both are what a proper review is looking for.
It sits between your data and the model. Its documented functions include masking sensitive data before a prompt is sent, a zero-retention arrangement so prompts and responses are not retained by the model provider or used to train third-party models, toxicity and safety scoring on responses, and audit logging of AI interactions. What it does not do is decide which records the agent may read — that is your permission model — or judge whether an answer is factually right. Treat it as a data-handling control, not a correctness control.
Do not give it the ability, or put a human between it and the consequence. Classify every action by reversibility and impact: reversible, low-impact operations can run unattended; anything financial, contractual or legally significant goes behind an approval step where a person authorises the specific instance. Relying on an instruction that says the agent should ask first is not a control — it is a preference the agent will usually honour, which is a different and much weaker claim to make to an auditor.
Conversation transcripts are retained against the record, and the platform logs AI interactions including what was sent, which model responded and what Trust Layer handling applied. The critical detail is the retention window: platform audit data is kept for a defined period, which may be shorter than your regulatory or contractual obligations. If you need to reconstruct a conversation from eighteen months ago, that requires exporting interaction records on a schedule you control. Design that before launch; it is very difficult to obtain retroactively.
That depends on your obligations, your jurisdiction and your own risk appetite, and it is a decision for your compliance function rather than for us or for Salesforce. What we can do is make the assessment possible: document exactly which data the agent reaches, what masking applies before anything leaves the org, what is retained and for how long, where human approval sits, and what evidence each control produces. Verify current platform certifications and data-residency commitments with Salesforce directly at the time you assess — those change, and we will not characterise them for you.
Whoever already owns data and access risk, extended to cover agents — not a new committee. In most mid-market organisations that means the person accountable for Salesforce security working with whoever signs off data handling. What matters is that someone specific approves what each agent may reach, that changes to that boundary go through them, and that re-verification has an owner and a date. The failure mode is diffuse ownership, where the first agent was carefully governed and the fourth was configured by whoever had admin rights that week.
Next Step
If you cannot state what your agent can read, start here
Bring your agent, live or in build, and whoever owns risk. We will map the real exposure, separate the controls from the instructions, and produce the evidence pack that turns a review into a signature.
Salesforce, CRM & AI delivery for growing and mid-market companies · Contact the team
