By: Andrew Purpura, CEO, Revecast

I’ve spent months interviewing people from large enterprises, including Salesforce, about the Shadow AI problem. Most of them are using AI their employer never approved.

Shadow AI is Already in Your Salesforce Org

I’ve had a lot of conversations over the past several months. People from large firms, enterprise software companies, global SIs, and yes, people who work at Salesforce. A fair number of them are talking to us in the first place because they’re frustrated with how their current employer is handling AI.

What they tell me is that they’re using AI their company never approved. They are not sheepish about it and they don’t treat it as a confession. It’s closer to an explanation of how the work actually gets done. Claude Code on a personal account because procurement hasn’t gotten to it. Or their own IT team approved something, but the customer’s contract doesn’t include it, which leaves them stuck in the middle with a deadline. That last version is where I hear the most frustration, because the person isn’t trying to get away with anything. They want to do the work well and the rules haven’t given them a way to.

It’s also rarely one tool. Somebody will use one thing for writing Apex, something else for documentation, something else again when they’re reasoning through a data model. They’ve each assembled a personal toolkit, picked task by task, that their employer has no visibility into and often didn’t authorize. Almost nobody I talked to could tell me their company’s AI policy matched what they actually do during the day.

The Published Numbers Line Up With What I’m Hearing

Verizon’s 2026 Data Breach Investigations Report (DBIR) found that 45% of employees are now regular AI users on corporate devices, up from 15% the year before. The more interesting number is that 67% of those users are reaching AI services through non-corporate accounts on company hardware. Personal login, company laptop. Shadow AI detections went up fourfold year over year and it now ranks as the third most common non-malicious insider action Verizon tracks. The largest category of data being uploaded, by a wide margin, was source code.

PagerDuty ran a survey through Wakefield Research covering 1,250 office professionals in non-IT roles at companies above $500 million in revenue. Two thirds had used AI at work while believing it wasn’t permitted, a third had entered customer data into public models, and 39% said they’d rather use AI without telling anyone than risk being told they couldn’t. Four in ten people have decided that asking is the riskier move, which I don’t read as a discipline problem so much as people responding sensibly to how their employer has set things up.

The Einstein Trust Layer Covers Less Than You Think

Salesforce has done real work here and I want to be fair about it. The Einstein Trust Layer masks sensitive fields before prompts leave the platform, runs under a zero data retention policy with external model providers, grounds prompts against the executing user’s permissions, applies prompt defense and toxicity detection, and writes an audit trail. If you’re deploying Agentforce, use all of it. The architecture is good and it does what it says.

What it governs is AI running inside Salesforce, and that scope is where the trouble starts. It does nothing about a developer pasting an Apex class into a personal ChatGPT account to work out why a trigger is recursing, or a consultant dropping a client’s field list into a chat window to draft a data dictionary, or somebody loading a sandbox extract to generate test data. Your Trust Layer dashboard will look completely clean the whole time that’s happening in the next browser tab. And remember what the DBIR said was the top upload category. Source code. For us that means Apex, flows, LWC, named credential configuration, and org metadata that spells out in detail how a regulated client runs their business.

The Gaps the Einstein Trust Layer Doesn’t Close

There are a few other gaps worth knowing about, though these tend to show up in year two rather than week one: 

  1. The running user: Every Agentforce agent is tied to a running user whose permissions define what it can reach, and new agents start with none, which is the right default. What goes wrong is what happens next: the agent throws permission errors during testing, someone is demoing on Friday, and the fastest way to make the errors stop is to point the running user at a profile that already works, usually an admin. The demo goes fine, nobody revisits it, and now there’s an agent that can read the whole org because of one bad afternoon. 
  2. Data Cloud policy: Enforcement only reaches as far as its ingested or federated footprint, so once your agent is touching Snowflake or Databricks you’re extending policy by hand. 
  3.  Masking: The Einstein Trust Layer masks sensitive fields before a prompt leaves Salesforce. But the more you mask, the less accurate the AI’s answers get. That means masking can’t be your main safeguard. Access design, controlling what the agent can reach before it ever gets to a prompt, has to carry that weight instead.

In a press release from May 2026, “Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure,” Gartner predicts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents due to governance gaps identified only after production incidents occur. 

The Paperwork Problem: What Shadow AI Costs You

If you run a services organization or an ISV there’s a second exposure that has nothing to do with data leaking. It isn’t only MSAs, either, which is what most people picture. It shows up in procurement packets. Security questionnaires, vendor assessments, the HECVAT if you sell into higher education. I filled out a stack of these recently for a procurement, and the AI questions in them have gotten a lot more specific in the last year. They ask: which models are used, were they trained on our data or not, where do the logs live and who can see the output?

Now put that next to what people told me in those interviews, where unapproved tools are running on live client engagements right now. Some number of firms are answering those questionnaires without a way to verify their own answer. There’s no log and no attribution, so when a client asks whether AI was used on their engagement and against what data, the honest answer is that nobody actually knows. That’s a hard position to be in, because the question is only going to get asked more often, and you either have the record or you don’t.

7 Steps to Build a Sanctioned AI Program on Salesforce

1. Ask People What They’re Using

Start by asking rather than investigating. Tell your team you’re trying to work out what to buy and support, not who to discipline, and then actually behave that way when they answer. The point of the exercise is fixing the gap.

What you’re writing down is the job each tool is doing, not the name of the tool: generates Apex from a described requirement, explains flow logic in an org nobody on the team has seen before, drafts the technical design document. That list of jobs becomes the requirements for everything after this, and if you skip it you’ll end up building a program aimed at problems your company doesn’t have. Afterward you can check against telemetry, non-corporate account sign-ins on managed devices and egress to AI domains, mostly to size the distance between what people said and what’s really going on.

2. Give Every Job on That List a Sanctioned Path

This is where these programs usually fall apart. Policy without supply doesn’t reduce usage, it just moves it somewhere you can’t see. If you take away a tool that turns a four hour Apex task into twenty minutes and give someone nothing in its place, you haven’t solved your risk problem, you’ve handed it to them, and they’re going to solve it in whatever way lets them hit their work commitment. The sanctioned path has to be at least as fast as the unsanctioned one or none of this holds.

When you map the jobs to paths, split them correctly. Runtime jobs are the ones happening in the flow of CRM work, things like summarization, drafting, service replies, and guided actions. Those go to Agentforce and Einstein Trust Layer, where the governance already exists. Delivery jobs are building, migrating, integrating, testing, and documenting, and those don’t map there at all.

It’s worth being precise about why, because this is the distinction the whole article turns on. The Einstein Trust Layer governs AI that runs inside your org. Delivery work doesn’t run inside your org, it produces what runs inside your org. Writing the Apex, designing the integration, generating the test coverage, drafting the spec, none of that is a Trust Layer event and there’s no Salesforce-provided governance covering it. It’s the same gap as the developer with the personal ChatGPT account, just at company scale.

That’s the category we built Revecast Orchestrate for. It’s two pieces: a Salesforce-native component that lives in your org, and an external delivery engine where the AI work happens. 

  • One plain-language prompt stands up a delivery team working in parallel, architect and developer and QA engineer and security engineer and technical writer, wired into Salesforce, Jira, and GitHub so the output lands where the work already lives.
  • On the governance side, this is a sanctioned path in the sense that matters to a procurement team. We’re SOC 2, we’re HIPAA ready, we’ll execute a BAA, and we hold agreements with our model providers, Anthropic included, that prevent them from training on customer data. Every session is logged. That’s the answer to the questionnaire question, and it’s an answer you can hand to a client rather than an assurance you hope holds up.

3. Write the Data Rules in Plain Terms

Telling people not to put confidential information into AI tools is too vague to follow. Everyone ends up making their own call, and you end up with as many data policies as you have employees. Write the rules in the vocabulary people actually use during the workday.

  • Things that never leave a governed path: production record data, any PII field, real customer names in test payloads, credentials and named credential configuration, and full org metadata for clients in regulated verticals. 
  • Things that are fine in a sanctioned tool: Apex patterns and algorithms, schema shapes without values, error messages with identifiers stripped, and anonymized or synthetic data. 

Then give people somewhere legal to work, which usually means a scratch org with a decent anonymized dataset that’s easy to get to. Most of the boundary problems I heard described weren’t defiance at all. Somebody needed realistic data late at night and had one way to get it.

4. Keep a Record of the Work

Six months from now somebody is going to ask about a specific Apex class in a client’s org. Who built this, what were they asked to do, and what could they see when they did it. A sanctioned program can answer that. A shadow AI program can’t.

I want to be careful about what we can do here today, because this is exactly the kind of claim that gets oversold. Orchestrate logs every session, so you have a record of the work that was done and by which resource, and we can show output volume against what the equivalent human effort would have been. We can tie the work all the way down to the time entry level by integrating Revecast Orchestrate with Revecast PSA.

The important part is that whatever record you keep has to be a property of the tool rather than a step in a process. If logging depends on someone remembering to log, your audit trail is fiction. Set retention deliberately too. If any of your agents land in EU high-risk territory, Article 26(6) of the AI Act requires deployers to keep automatically generated logs under their control for at least six months. Most Agentforce deployments won’t be classified high-risk, but it’s better to answer that question on purpose than to find out later.

5. Scope Your Agents Properly

Salesforce starts every agent’s running user with no permissions, and most teams undo that in week one for the reason I described earlier. Make the running user something you actually review. One per agent, purpose-named, never shared between agents and never a person’s account, because shared identity means you can’t revoke or investigate one agent without hitting another. Scope the permission sets to that agent’s real topics and actions and grant them additively as you build, since an agent that summarizes cases has no business reading compensation. Then review what each running user can reach on the same cadence you’d apply to any other privileged account, because permissions get added under deadline and never get taken away.

Do this while you still have three agents. Non-human identities already outnumber human ones badly, with research cited by the Cloud Security Alliance putting the ratio near 45 to 1 and higher in cloud-native environments. You aren’t going to retrofit this across a population that size.

6. Monitor It Like Production and Keep Approval Fast

We built the agent live on Jax Consulting’s site in four days with one person, and put six monitoring layers on it.

Worth separating the pieces here, since people conflate them. Revecast Orchestrate built the agent. The agent itself runs on Salesforce’s headless Agentforce API.

Here’s what’s actually watching it:

  • Daily conversation scoring. Every visitor conversation gets scored by an AI evaluator on a 1 to 10 scale, tagged for sentiment and issue category, and written to a custom Salesforce object.
  • Weekly synthetic testing. Seven scripted conversations run every Monday against the live agent, asserting persona, routing, and lead capture.
  • Hourly uptime checks. Four production endpoints get hit hourly with real HTTP requests.
  • Daily device testing. Playwright runs the agent through six device emulations every morning and confirms audio actually plays, using the real browser onplaying event instead of a proxy for it.
  • Queryable alerting. Every alert gets logged as a Salesforce Task, and automated cleanup keeps synthetic test data out of the real AE pipeline.

Most agents running in production today have none of that, and they drift quietly until a customer notices something is wrong. We built six layers on what started as a personal experiment because it was roughly as cheap to build them as to skip them (which is the real argument for a sanctioned program). Sanctioned AI isn’t slower AI with paperwork attached. It’s the setup where monitoring gets cheap enough that you actually do it.

The other half of this is keeping approval fast, because governance that’s technically correct and operationally unusable just teaches people to route around it. If a change takes two weeks and three meetings, you’ve rebuilt the shadow AI program with extra steps. 

Our loop is that the QA layer surfaces something, whether that’s persona drift or a missed routing call or a degraded response, Orchestrate proposes a fix, and we approve it, usually in Slack, on a phone, in a few seconds. 

I want to be careful here because this gets oversold constantly. The agent does not modify its own prompts and there’s no autonomous self-modification anywhere in that loop. It’s an observability and remediation cycle with a person in the middle of it, running at minutes instead of weeks.

7. Hire for It

The first six steps are systems. This one is people, and it decides whether the rest holds up.

Nobody says this part out loud, but the variance is the problem more than the average. If half your team is working with AI and half isn’t, you don’t have a team running at one and a half times speed, you have two teams moving at very different rates across shared codebases and shared deadlines. Estimation stops working, because the same piece of work is two days or two weeks depending on who picks it up, and planning gets harder for everyone. The answer isn’t to slow the fast half down to make the numbers consistent. It’s to get the whole team to where the fast half already is, and that starts with who you hire.

So hire for it, and say so in the job description. Put it in the interview as an actual working session with a real task and a real tool where you watch what someone does, not as a values question people can pattern-match their way through. Forty minutes of that tells you more than any amount of asking candidates to describe their experience with AI. What you’re looking for isn’t enthusiasm, it’s judgment. Somebody who accepts every generated result without checking it is a bigger problem than a careful skeptic, because they’ll ship things nobody on the team understands and you’ll maintain them for years. The person you want treats the model like a fast colleague whose work still gets reviewed.

The Uncomfortable Truth About Your AI Program

A few things I’ve concluded from these interviews that I don’t think people especially want to hear. The first is that if you have an AI policy and no AI supply, you don’t really have a program, you have a document. The usage is happening either way, and right now the main thing the policy accomplishes is making sure you can’t see it. That’s worth sitting with, because most of the leaders I talk to believe the policy is doing more than that.

The people going around you mostly aren’t doing it to be difficult. They went around you because there was a gap between what you asked them to deliver and what you gave them to deliver it with, and they closed it themselves. 

And you aren’t deciding whether to start an AI program, because you already have one. The real question is narrower and more urgent than whatever is on your roadmap right now. Is the AI program you already have one you can see, log, and defend? Or is it the one running in a browser tab, on somebody’s personal account, against your client’s data?

This applies differently depending on where you sit:

  • If you are a CIO or CISO, start by asking your team what they’re using. You’ll learn more in two weeks than in two years of policy review. 
  • If you are an ISV, your customers are going to start asking which models touched their data and where the logs live, and some already are.
  • If you run a services organization, go look at the AI questions in your last three procurement packets and then ask your delivery leads what’s actually being used on those accounts. If those answers don’t match, that’s your whole project.
  • If you are a Salesforce account executive with a customer stuck between an AI policy and an AI reality, that gap is what we build. Talk to us before somebody scopes it as an eighteen month governance transformation.

How Revecast Orchestrate Fits In

If you’re evaluating Revecast Orchestrate, know that this isn’t a governance module you buy on top of a product. The logging, the SOC 2, the BAA, and the provider agreements that keep your data out of training runs are all part of how the work gets done, in the layer where Salesforce doesn’t give you any coverage.

A sanctioned AI program only works if people actually use it, and only holds up if you can defend it later.

Learn more about Revecast Orchestrate.

Table of Contents