Aetrum LLC now does business as Trevaun. Same company, new brand. Read the noteAetrum LLC now does business as Trevaun. You followed an Aetrum link. Aetrum LLC now does business as Trevaun: same company, new brand. What changedAetrum LLC now does business as Trevaun.

Govern

Decide what your AI agents can reach and do, and keep it that way.

An agent is not a new security model. It is a new consumer of the one you already have. We decide what each agent can reach and do, then build the controls around it: its identity, the actions it may take, who approves what, and how you see what it did.

Who it is for

This fits if you are here.

  • You are deploying an Agentforce agent this quarter, or connecting an outside model to Salesforce through OAuth.
  • Your agents are live, and no one has signed off on what they can see and do.
  • You are planning more agents and want one set of controls they all run inside, not a new debate for each.
What you get

The controls we put in place.

  1. The right identity for each agent

    The person's own access for employee agents. A dedicated, least-privilege user for service and outside agents. Never a cloned admin.

  2. An action allowlist

    Which Flows, Apex, prompt templates and APIs each agent may call, and which need a person to approve first.

  3. Logging you can audit

    What each agent changed and answered, and what it read where your licenses log it, for example in Event Monitoring or Agentforce session data, kept where your team can review it.

  4. Tests before every release

    A set of test conversations and expected outcomes, rerun whenever the agent, its prompts or its access change.

  5. An owner and an off switch

    A named person accountable for each agent, and a written way to pause it.

What an agent can reach depends on its identity and how its actions runAn employee agent, used by staff in Salesforce, runs as the logged-in user with the person's own access. A service agent, which talks to your customers, runs as a dedicated, least-privilege agent user. An outside agent, a custom or vendor model, enters through an External Client App or Connected App with an OAuth flow and scopes, and runs as the Run As user or the end user depending on the flow. Each identity has an owner named by you. Then the action context: Apex and Flows that run in system mode can reach past the identity's own access. Together that sets effective access: permission sets, sharing, field-level security and OAuth scopes, which decide the records the agent can reach and change.Employee agentused by staff in SalesforceService agenttalks to your customersOutside agentcustom or vendor modelLogged-in userthe person's own accessagent owner: named by youAgent userdedicated, least privilegeowner: named by youExternal Client Appor Connected AppOAuth flow and scopesRun As user or end userdepends on the OAuth flowowner: named by youAction context: user mode or system modeApex and Flows that run in system mode can reach past the identity's own accessEffective accesspermission sets, sharing, field-level security, OAuth scopesRecords the agent can reach and change
What an agent can reach depends on its identity and how its actions runAn employee agent, used by staff in Salesforce, runs as the logged-in user with the person's own access. A service agent, which talks to your customers, runs as a dedicated, least-privilege agent user. An outside agent, a custom or vendor model, enters through an External Client App or Connected App with an OAuth flow and scopes, and runs as the Run As user or the end user depending on the flow. Each identity has an owner named by you. Then the action context: Apex and Flows that run in system mode can reach past the identity's own access. Together that sets effective access: permission sets, sharing, field-level security and OAuth scopes, which decide the records the agent can reach and change.Employee agentused by staffLogged-in userthe person's own accessowner: named by youService agenttalks to customersAgent userdedicated, least privilegeowner: named by youOutside agentcustom or vendorExternal Client Appor Connected AppOAuth flow, scopesRun As or end userdepends on the flowowner: named by youAction context:user mode or system modesystem-mode Apex and Flows can reachpast the identity's own accessEffective accesspermission sets, sharing,field-level security, OAuth scopesRecords the agentcan reach and change
From Part 1 of our series on governing AI agents in Salesforce.
Governance

Five questions, answered in writing before go-live.

Teams that can answer all five tend to have boring go-lives.

Identity
What identity does the agent run as, and is that identity dedicated to this agent alone?
Effective access
Not the intended access: the computed result of permissions, the sharing model, system permissions and, for outside agents, the OAuth flow and scopes.
Action reach
What can each action reach beyond the agent's own identity? Flows, Apex, prompt templates and APIs run in their own context, and some run with more access than the agent has.
Widened access
What access was widened during the build, and is each widening still justified?
Sign-off
Who signs off on this access, by name, before the agent goes live?
How it works

From first call to result.

  1. Scoping call

    Which agents, which platform, and which data they touch.

  2. Read-only reviewFixed scope

    We trace each agent's identity, effective access and actions, on Agentforce or through the app definition an outside agent uses.

  3. Governance readout

    Written answers to the five questions above, gaps ranked by risk, and the fixes in order.

  4. Put the controls in place

    Identities, allowlists, approvals, logging and tests, set up in your org and handed over.

  5. Keep it true

    Optional: we review agent changes as they come, so the controls hold as you add agents.

Pricing

Fixed price, scoped after a short scoping call.

Review only, or review and controls: you choose after the scoping call. Already live? The Org Access Assessment reviews who and what can reach your Salesforce data, agents included.

Proof

Led by a certified Salesforce architect. Trevaun is a Salesforce Consulting Select Partner.

Built the Salesforce integration behind a production agentic customer support platform delivered with Sierra AI, connecting case and subscription data to an AI agent layer.

Read the series: Governing AI Agents in Salesforce, Part 1: The Access Your Agent Inherits.

  • Salesforce Partner
  • Pledge 1% member
FAQ

Questions people ask.

What controls do you put in place?

The identity each agent acts as, the actions it is allowed to take, the approvals it needs, the logs it leaves, and the tests it must pass before a change goes live. Governance decides the rules. The controls enforce them.

Does this apply if we are not using Agentforce?

Yes. An outside agent enters through OAuth against an External Client App or Connected App. The vendor differs; the access question and the controls are the same.

Isn't a new agent locked down by default?

A new platform agent has no grants of its own. In practice it is given a cloned user or a template permission set, which is where access widens.

Can you also build the agent?

Yes. We build Agentforce agents, and design their access before they ship. See Salesforce Implementation and Agentic Development.

Do you change anything during the review?

No. The review is read-only. Controls are set up only after you approve them.

Put controls around your agents before they scale.

We reply within one to two business days.