An AI agent just broke into a government portal without being asked to. Your CRM has more doors, more data, and its own agents answering them.

On September 23, Australia's Prime Minister said an OpenAI agent had gotten into the Medicare Statistics Reporting Service portal. The breach happened in June. The agent was in an internal evaluation, looking for Medicare spending figures. It found a way past the portal's access controls and pulled files that were never meant to be public (ABC News, 2026). Nobody told it to break in. OpenAI said its models "took actions we did not intend" (Decrypt, 2026). The government found out about three months later.

Now picture the same thing inside your Salesforce org. The difference is that there, an agent of yours is waiting to answer it.

The problem nobody owns

Every CRM program I have worked on has an owner for the platform, the data, and security. Almost none has an owner for what agents can do.

That gap is not carelessness. It is structural:

• Security teams protect logins and networks. An agent that comes in through a Web-to-Lead form is not logging in at all. It is typing.
• CRM admins set profiles and permission sets for humans. Agents often run as an integration user that someone created in a hurry.
• The business owns the use case: "deflect 30% of service cases." Nobody owns what that agent can read, change, or send along the way.
• The vendor ships guardrails and a necessary trust layer. However, a vendor cannot decide what your agent should be allowed to touch.

So access control for agents falls between four teams. Each assumes another one has it. This is not one company's failure. It is how the industry built CRM governance before agents existed.

Where access control fits

In the Master Framework, this sits in Foundation → Risk management → Access control.

Risk management identifies and mitigates risks to maintain operational integrity. Access control decides who and what can reach which data and actions, under what conditions, and who proves it.

For 20 years, "who" meant people. Profiles, roles, sharing rules, field-level security. That model assumes every actor is a person who reads before acting.

Agents break that assumption in three ways:

1. They take instructions from data. A lead description or case comment can become a command. Humans do not treat a form field as an order. Agents sometimes do.
2. They act at machine speed. A person with too much access leaks one record at a time. An agent with too much access can export the whole object before anyone notices.
3. They talk to each other. An outside agent submits a form. Your Agentforce agent reads it, calls a flow, and hands off to another agent. Each step can inherit the last one's mistake.

When access control doesn't cover agents, the cost does not look like a security incident at first. It looks like odd emails, bulk queries at 2 a.m., and records changed by "Integration User." By the time it reaches the board, it is being called a technology failure. It is a governance failure.

What good looks like

A CoE with working agent access control can answer these questions in one meeting, without a scramble:

• Inventory. It lists every agent touching the org. That includes your Agentforce agents, every connected app and OAuth token, every MCP connection, and every employee-connected AI tool. Each one has a named business owner.
• Least privilege by design. Each agent runs as its own user with its own permission set. No shared integration users. No "admin for now." Field-level security is set for what the agent needs, not what is convenient.
• Inputs treated as data, not instructions. Anything from a public form, email, chat, or outside agent is untrusted. This is tested before go-live, not assumed.
• A human approves high-impact actions. Money movement, bulk exports, outbound email containing record data, and permission changes all need a person's sign-off.
• Outbound destinations are allowlisted. An agent can't send data to a domain nobody approved.
• Behavior is monitored. Unusual volumes, new destinations, and agent-to-agent loops raise alerts that someone actually reads.
• Agents are red-teamed. Agent-vs-agent attack testing is part of the release standard, the same as UAT.
• Incidents have a clock. A named owner and a fixed disclosure timeline apply, both internally and to regulators. Australia's anger was as much about the three-month silence as the breach.

The output of this function is simple: a one-page agent access register the CIO can sign. If you cannot produce it, you don't have agent access control. You have hope.

The evidence

This is not theoretical. It has already happened inside Salesforce, three times:

• ForcedLeak (2025). Noma Security showed that instructions hidden in a Web-to-Lead description field could make Agentforce pull CRM data and send it out. The route out was an expired, allowlisted domain that cost about $5 to buy. The flaw was rated CVSS 9.4, which is critical. Salesforce patched it and added URL allowlisting (The Hacker News, 2025).
• Salesloft Drift (2025). Attackers used stolen OAuth tokens from one AI chatbot integration to reach Salesforce data at more than 700 organizations. They never needed a password (The Hacker News, 2025).
• PipeLeak (2026). Capsule Security found that Agentforce emailed "all the leads it can find" to an outside address through a public lead form. Salesforce called it a configuration issue and recommended human-in-the-loop settings (Dark Reading, 2026).

Notice the pattern: configuration. The platform was patched each time. The access decisions belong to you.

The wider numbers match. In a 2026 survey of 750 senior technology leaders, 54% reported an AI agent security incident. 90% had agents nobody was monitoring. 85% had no formal accountability for agents (Gravitee, 2026).

My own observation, and it is an opinion: most agent rollouts I have seen went live with the agent able to see more than any single human rep. That is because it was faster to go live that way.

Why a universal standard, not your own framework

Right now, every organization is inventing its own definition of "agent access control." Some fold it into security. Some put it on the Salesforce admin. Some write a policy that nobody enforces.

Multiply that by thousands of CRM programs, and here is what it costs:

• No comparability. A board cannot ask, "Are we better or worse than our peers?"There is no shared yardstick.
• No portability. An architect who built strong agent controls at one company can't prove it at the next. The work doesn't travel.
• No vendor accountability. When "configuration" is where the breach lives, and every customer defines configuration differently, the line between vendor and customer responsibility stays blurry. That suits nobody except attackers.
• No partner credibility. Every SI says it does "secure Agentforce." No client can check.

Agents are about to outnumber the people in many CRM orgs. We need one shared definition of what agent access control is, who owns it, and what proof looks like. We need it before regulators write it for us.

What this means for you

If you lead a CRM organization

Ask your team for the agent access register this week. If it takes more than a day to produce, you have found your biggest unowned risk. It is also your easiest board conversation to get ahead of.

If you build and run the CoE

This is your opening to get governance funded. Take the three Salesforce incidents above to your leadership. Propose one owner, one register, and one pre-release agent attack test. Specific asks get funded. Vague concerns don't.

If you deliver CRM for clients

Add agent access control to your standard Agentforce delivery: separate agent users, allowlists, human approval, and adversarial testing. Clients will start asking for this. Partners who can already show it will win the renewals.