# The security model behind an agent: permissions, grounding and blast radius > An agent does not introduce a new security model. It interrogates the one you already have, faster and more thoroughly than any employee ever did. - Source: https://synconai.com/insights/agentforce-security-best-practices - Publisher: SynconAI (https://synconai.com) - Desk: AI & Agentforce - Author: SynconAI Architecture Team, Solution & technical architecture - Published: 2 February 2026 - Updated: 29 August 2026 - Reading time: 15 minutes - Topics: Agentforce, Security, Permissions, Governance, Data access ## Key points - The agent sees what its running user can see. Choosing that user is an architecture decision, not a setup step. - Composition is the genuinely new risk: an agent assembles into one answer what a person would have gathered across four screens. - Record sharing and knowledge visibility are separate access paths, configured separately and almost always audited separately. - Blast radius is about writes. Put the guardrails in the action, where they hold regardless of what invokes them. --- The first security question we get asked about an agent is almost always which permission set it should have. That is the right instinct pointed at the wrong altitude. The permission set is a consequence. The decision underneath it is which user the agent runs as, and that decision is usually made in about ninety seconds by whoever is doing the configuration, on a Tuesday, with nobody from risk in the room. It is worth being clear about what has and has not changed. An agent does not introduce a new security model. It runs inside the one you already have, and the [Salesforce Platform](https://www.salesforce.com/platform/) enforces sharing for an agent the way it does for a person. Nothing about that is new or negotiable. What is new is the thoroughness of the questioning. A human user with broad access does not read every record they are entitled to read. They read the ones in front of them, at the speed a person reads, on the screen they happened to open. That practical limit was never a control, but it functioned as one for decades. An agent removes it, and in doing so it turns every latent over-permission in your org into a live one. ## The running user is an architecture decision The agent operates as a user. That user has a profile, permission sets, a role, ownership, sharing rules and every other access grant your org has accumulated. What that user can see, the agent can surface: phrased helpfully, in a sentence, to whoever is on the other end of the conversation. Say it back to yourself in those terms and the choice stops feeling like an admin detail. You are not assigning a licence. You are defining the outer edge of what a customer-facing system can say about your business and your customers. Three failure patterns turn up repeatedly. **Reusing an existing integration user.** This is the fastest path to a working agent and the worst one. Integration users tend to be broadly permissioned by design, because they were built to serve several systems and every new integration added a little more. Nobody ever removed anything. Pointing an agent at that user hands it an access footprint assembled for entirely different purposes. **Cloning a human's access.** Better in intent, still wrong. A service consultant's permissions cover their whole job: the cases they handle, the reporting they run, the occasional escalation, the quarterly audit request. The agent does one narrow slice of that job. Cloning the consultant grants the rest for free. **Starting from an admin profile and planning to trim.** The trimming never happens, because by the time anyone gets to it the agent is working and nobody wants to be the person who broke it. Build the running user upward from nothing, one grant at a time, each tied to an intent you can name. ::: note The useful test is a sentence, not a report. Write down what the agent can see in one plain sentence, and if you cannot, the running user is too broad to launch. That constraint is why we prefer a purpose-built user with a dedicated permission set over any inherited one, however convenient the inherited one looks on the day. ::: The related discipline is that this user should not be quietly widened later. Access requests arrive against agent users the same way they arrive against everything else, usually framed as a small addition to fix one intent. That is precisely the mechanism that produced [permission set debt](/insights/permission-set-debt) everywhere else in the org, and an agent user is a worse place for it than most, because the consequences are customer-facing rather than internal. ## Composition changes exposure without changing permissions This is the part that is genuinely different, and it gets the least attention because it does not look like a security finding. Nothing is misconfigured. Every access check passes. And the effective exposure of your data has still changed. Consider a running user permitted to read the account record, the related contacts, open cases, and closed won opportunities. Every one of those grants is defensible in isolation, and a reviewer working through them one at a time would approve all four without hesitating. Now ask an agent a broad question. It reads across all four, synthesises, and returns one paragraph containing the account's renewal date, the name and mobile number of the executive sponsor, the fact that there were three severity-one cases last quarter, and the discount applied on the last deal. No permission was exceeded. Nothing was leaked in the technical sense. A person could have assembled the same paragraph by opening four screens, cross-referencing and typing it out. The difference is that they would not have. The effort was never a control, but it was a filter, and it filtered out almost all of the assembly that was theoretically possible. The agent removes the filter and does the assembly on request, in a second, for anyone who asks a question that happens to reach it. We call this composition risk, and the reason it matters for governance is that it is invisible to every review process most organisations run. Permission reviews evaluate grants one at a time. Composition is a property of the set, not of any member of it. You can review each row, approve each row correctly, and still have approved something nobody would have approved as a whole. There are three practical responses, and they compound. **Review the grant set as a set.** For each agent, list the objects and fields its running user can read, then ask what the most sensitive true statement is that could be constructed from all of them together. That statement is your actual exposure. Write it down. It is a far more useful artefact than a permission matrix, and producing it takes about an hour. **Scope by intent rather than by role.** A human needs broad access because their work is unpredictable. An agent's work is not: it handles a defined set of intents, and the union of what those intents require is almost always narrower than any role. Start from the intent list and grant only what each intent genuinely needs, then treat any grant that cannot be traced back to an intent as a defect. **Be deliberate about field-level access, especially on fields nobody thinks of as sensitive.** Composition risk lives in combinations. A mobile number is not confidential on its own, and neither is a renewal date, but a sentence containing both, about a named executive, is a different object. Field-level security is the cheapest control available here and it is routinely left wherever the role inherited it. ::: warn Composition risk is not solved by instructions telling the agent what not to discuss. Instructions shape behaviour, they do not enforce boundaries. If a fact must never be assembled, the underlying access should not permit reading it. Anything else is a preference expressed in English, and the only durable boundary is the one the platform enforces. ::: ## Two access paths, audited as one Record data is not the only thing an agent reads. It also grounds its answers in knowledge and content, and that path has its own access model, configured separately by different people, usually reviewed on a different schedule if it is reviewed at all. Record access is bounded by the sharing model through the running user. This is well understood, it behaves the way Salesforce administrators expect, and it is the path everyone audits. Knowledge and content visibility is bounded by its own rules: categorisation, channel or audience visibility, and whatever governs the repositories the agent is pointed at. An article marked visible to a public channel is available regardless of how carefully the record sharing was configured. The two models do not consult each other. The practical consequence is a specific and reasonably common failure: an agent correctly prevented from reading a case still quotes an internal troubleshooting article, or a pricing guideline, or a policy document written for staff on the assumption that only staff would ever read it. The record boundary held perfectly. The content boundary was never checked. | Access path | Governed by | Typically owned by | Usual audit status | | --- | --- | --- | --- | | Record data | Sharing model via the running user | Salesforce admin or platform team | Reviewed, sometimes formally | | Knowledge and content | Category and channel or audience visibility | Content, service or enablement team | Rarely reviewed against the agent | | Unified and external data | Source system access plus the unification layer | Data team | Reviewed at the source, not at the agent | | Action inputs and outputs | Permissions on the action itself | Development or platform team | Reviewed as code, not as access | The third row deserves a note. Once grounding extends beyond Salesforce records into unified data, the access question moves with it. If your agent reads from unified profiles in [Data 360](https://www.salesforce.com/data/) or calls an external system live, the boundary is now partly defined outside the org, and the review has to follow it there. The most common gap is a source system where access was scoped for a nightly batch integration and nobody re-examined it when a conversational surface was attached to the same credentials. The instruction we give is deliberately blunt. Audit every path independently, and never accept evidence from one path as evidence about another. Passing a record access test says nothing at all about content visibility. ## Blast radius: what the agent can write Reading is an exposure problem. Writing is a damage problem, and the two need different treatment. Reading widely is often the entire point. A service agent that cannot see enough context is useless, and the value of the thing is that it assembles context a person would have collected across several tabs. The composition controls above manage that risk. Writing is where a mistake becomes irreversible, and irreversible is the word that carries the weight. Blast radius is a simple question with an uncomfortable answer: if this agent misinterprets an instruction, what is the worst state it can leave the org in, and can that state be undone? Most teams have never asked it in that form. When they do, the list of write actions usually turns out to be longer than expected, because actions accumulate the way permissions do, one useful addition at a time. Four rules hold up well in practice. **One action, one job.** An action that creates a case is easy to reason about. An action that creates a case, updates the contact, sends an email and closes a related case is not, because approving it means approving four things at once and the review will only really consider the first. **Guardrails live in the action, not the agent.** This is the most important structural decision here, and it is the same principle we apply when [integrating agents with Service Cloud](/insights/agentforce-service-cloud-integration). Whether a refund, an entitlement change or a record deletion is triggered by an agent, a flow, an API call or a person, the validation, the limit check and the log entry belong inside the action. Put them there and they hold no matter what invokes them later, which matters because something else will invoke them later. **Irreversible actions need a human, or a ceiling, or both.** Reversibility is the right axis, not sensitivity. Creating a task is trivially undoable. Issuing a refund is not. Sending an email to a customer is not. Deleting a record is not. For anything on the wrong side of that line, either route it through an approval or bound it with a limit that makes the worst case survivable: a value ceiling, a rate limit, a scope restriction to records related to the current conversation. **Every write is attributable.** You need to be able to answer, later, which agent made a change, in which conversation, on whose behalf, and on what basis. Field history and audit trails give you part of this. The conversation context that explains why generally has to be logged deliberately, and no team has ever regretted logging it. ::: tip Run the blast radius exercise as a list, not a discussion. Write out every action the agent can invoke, mark each one reversible or irreversible, and for every irreversible row name the specific control that bounds it. Rows with no named control are your pre-launch work, and there are usually two or three of them. ::: ## Identity strength is a property of the channel An authenticated portal session and an unauthenticated chat window on a public page are not the same security problem, even when the agent behind them is identical and the customer's question is word for word the same. An authenticated session arrives with a verified contact, an account, and a relationship the platform can enforce. The sharing model does real work: scoping answers to this customer follows from knowing who they are. An unauthenticated visitor arrives with a claim. They typed a name, an order number, an email address. None of that is proof of anything. The failure this produces is well worn. An agent is built inside a customer portal, where account-scoped answers are correct and safe. It works. Someone extends it to the public site, because the intents look the same and the effort looks small. What has actually been built is a way to enumerate customer data by guessing identifiers, and it will not be found in testing, because everyone testing it is signed in. Treat identity strength as an explicit property of each channel and define, per intent, the minimum strength it requires. | Identity strength | What the channel established | What the agent should answer | | --- | --- | --- | | Anonymous | Nothing verified | General information only, nothing account-scoped | | Claimed | An identifier the visitor typed | Nothing sensitive without a verification step first | | Authenticated | A verified session tied to a contact | Account-scoped answers within the sharing model | | Authenticated and elevated | Verified session plus a step-up for a sensitive action | Irreversible or high-value actions | The row that gets skipped is the claimed one, because it feels like an edge case during design and turns out to be the majority of real traffic on a public channel. Decide in advance what a claimed identity earns, which in most organisations should be very little, and make the verification step a designed part of the conversation rather than an exception someone bolts on after a penetration test. ## The pre-launch security checklist This is the artefact worth taking away. Every row is answerable in a sentence, and a row you cannot answer is a finding rather than a gap in the checklist. | # | Check | Passes when | | --- | --- | --- | | 1 | Running user identity | The agent runs as a purpose-built user, not a cloned human or an existing integration user | | 2 | Grant provenance | Every permission on that user traces to a named in-scope intent | | 3 | Composition statement | The most sensitive true statement constructible from the full grant set is written down and accepted | | 4 | Field-level review | Sensitive fields are restricted explicitly, including fields that are only sensitive in combination | | 5 | Knowledge and content visibility | Content the agent can ground on has been reviewed against the agent, not only against staff audiences | | 6 | External and unified sources | Access to any non-Salesforce grounding source has been re-scoped for conversational use | | 7 | Write inventory | Every action the agent can invoke is listed and marked reversible or irreversible | | 8 | Irreversible controls | Each irreversible action has a named approval, ceiling or scope restriction inside the action | | 9 | Channel identity map | Each channel has a declared identity strength and each intent a required minimum | | 10 | Attribution and logging | Agent writes are traceable to a conversation, and conversation context is retained | | 11 | Negative testing | Tests exist that prove the agent refuses, not only that it answers | | 12 | Review owner and cadence | A named person re-runs this list on a defined schedule, not after an incident | Twelve rows, and the honest experience is that most organisations pass eight or nine on the first attempt. The three that fail are usually the composition statement, the content visibility review and negative testing, which is a fair summary of this article. ## Test the boundary, not the agent Almost all agent testing asks whether the agent gives good answers. That is a quality exercise. It is not a security one, and passing it comprehensively tells you very little about the boundary. Security testing asks the opposite question: can the agent be induced to give an answer it should refuse? The tests that matter are the negative ones. **Refusal tests.** Ask for something outside scope, directly and then indirectly. The indirect version is the informative one, because a request the agent recognises as out of bounds is easy, and a request that reaches the same data through a legitimate-sounding path is not. **Composition tests.** Ask a broad, innocuous, open question and read what comes back with an adversarial eye. Not whether it is accurate, but whether the assembled answer is something you would have approved as a document. This is the test nobody runs, and it is the one most likely to change a launch decision. **Cross-channel tests.** Run the same account-scoped intent through every channel and confirm it refuses where identity was never verified. Build environments are signed in by default, so this test has to be deliberate or it does not happen at all. **Content path tests.** Independently of record access, confirm the agent cannot surface internal-only content. Passing a record test is not evidence about this, and in practice the two are tested together and therefore neither is really tested. **Action tests with wrong inputs.** Call each write action directly with deliberately incorrect parameters. The agent will eventually supply incorrect parameters, and the action's own validation is the entire thing standing between that and a bad write. Automate the refusal set and run it on every change to instructions, grounding sources or actions. Refusal behaviour degrades quietly when a topic is added or a data source is extended, and the only reliable way to notice is to check every time rather than at the end. ## Reviewing it after launch Security posture is a state, not a milestone, and agent posture drifts faster than most because the things that shape it change often: a new intent, an extra grounding source, one more action, a helpful permission added to unblock something on a Friday. Three habits keep it honest. Re-run the twelve-row checklist quarterly, or on any material change to grants, grounding or actions, whichever comes first. Keep the composition statement current, because it is the artefact that ages fastest and the one most useful to a risk committee that has to sign something. And review agent write logs on the same cadence you would review any privileged account's activity, since that is functionally what this is. None of this is exotic. It is ordinary access governance applied to a user that happens to be tireless, literal, and talking to your customers. Teams that already run a disciplined access model will find the work incremental, which is the practical argument for cleaning up the model first. Teams that do not will find the agent surfacing every deferred decision at once, which is uncomfortable and, in fairness, useful. The broader delivery view of getting this right alongside everything else a rollout demands is in [what separates an Agentforce rollout that is still running in six months](/insights/agentforce-implementation-best-practices), and the platform-level view of how Salesforce approaches [cloud data security](https://www.salesforce.com/platform/cloud-data-security/) is worth reading alongside your own model rather than instead of it. The security work on an [Agentforce](https://www.salesforce.com/agentforce/) project is not a phase near the end. It is the shape of the thing, and it is decided at the moment somebody chooses which user the agent runs as.