A support bot's admin tools got exploited—not by tricking the model, but by exploiting the access model.
On 2026-09-02, researchers at Intigriti walked into a customer support bot wired with the same admin tools a lot of production support agents now carry—editing profile details, reading billing statements, transferring data or money to another account—and got out with access they shouldn't have had. The finding, presented at DEF CON 34's Bug Bounty Village and worth $50K+ in bounties in just a few weekends, wasn't a prompt-injection trick or a model talked into misbehaving. It was a support agent that never re-checked who was asking before it fired a tool that could move money. If your team already gave an agent admin tools to handle support, that's the question worth answering this week: when it invokes one of those tools, what's actually re-verified—the identity, the request, or just that the tool exists?
The DEF CON 34 finding: admin tools, exploited by identity, not the model
Ayoub and Inti De Ceukelaire's write-up, "Hacking AI customer service agents", names the exact capabilities they found wired into these bots: "editing your profile details, reading your billing statements, or even transferring data or money to another account." The root cause was upstream of the model: "some chatbots will fail to correctly verify the sender with the account owner." A spoofed identity or an injected instruction can ride an agent's already-granted tool access straight through, because nothing re-checks who's asking when the tool fires.
Intigriti frame the gap precisely: it sits "between where a human stops making thoughtful decisions and when an over-privileged AI agent takes over." GBHackers' coverage, six days later, corroborates the pattern without naming a vendor—this isn't one bot's bug, it's structural in how support agents get wired up.
What is AI agent access control, and why didn't it catch this?
TL;DR: AI agent access control usually covers two decisions made once, at setup—which tools an agent gets, and what data it can see. The DEF CON 34 exploit lived in the gap neither decision answers: what gets re-verified when the tool call actually executes.
Access control, for an AI agent, is usually two decisions made once, at setup: which tools does this agent get, and what data can it see. A support agent gets a refund tool because refunds are part of its job, and read access to billing because it needs it to answer questions. Reasonable, necessary decisions—and where most teams stop.
What DEF CON 34 found is the gap after that decision: nothing re-checks, when the refund tool fires, whether this specific request is the one the setup-time grant was meant to cover. The agent already has the tool; the exploit answers a different question—who's actually holding the wheel when it uses it.
That gap isn't rare. Kiteworks' 2026 forecast report found 63% of organizations can't enforce purpose limitations on their AI agents, and 60% can't terminate one that's misbehaving. The access was granted once, at setup, and for most organizations nothing checks what it's used for after that.
Salesforce solved half of it: give the agent its own identity
Salesforce's Agentforce actually built a real answer to half of this problem. Its autonomous, customer-facing Service Agents don't run under a human's permissions or a shared service account—they get their own synthetic identity, called an Agent User, that an admin configures with its own permission sets. Per Salesforce Ben's write-up on Agentforce permissions, when you create a new agent and choose the "New User" option, "Salesforce auto-creates a user record for it," done specifically so the agent "doesn't inherit anything from your existing profiles or permission set groups." The bundled permission set group has a name—AgentforceServiceAgentUserPsg—plus a Secure Base set and an empty per-agent set the admin fills in by hand.
That's a genuinely different model from a user-invoked copilot, which just inherits whatever the logged-in human can already see. An autonomous agent with nobody behind it can't borrow a human's permissions, so Salesforce built it a standing, admin-configured identity instead. A real, useful answer to "what can this agent see and touch inside our CRM."
Where the SaaS permission set stops mattering
Here's the problem: Agentforce's Agent User model, and permission-set thinking in general, only govern one layer—the SaaS platform itself—and most real "give the agent admin tools" setups don't stay inside one SaaS platform. The refund tool your support agent calls is often a webhook that runs an internal script against your billing database. The "edit profile" action might hit an internal API, not a Salesforce object. A tool wired up through MCP might reach a production host directly.
The moment that happens, a permission set stops being the control that matters. Salesforce's Agent User can correctly say the agent may see this billing field and call this Apex action—and still say nothing about what that action does once it reaches your own infrastructure, because that's not Salesforce's layer anymore. Same pattern elsewhere: Zendesk gates who can configure the bot, and Intercom additionally gates which knowledge sources it's synced to—both admin-side governance of setup, not a runtime check on the interaction itself. Neither vendor's docs describe a per-action check layered on top of identity, which is exactly the gap Intigriti found exploited.
Access control—SaaS or otherwise—answers whether the agent is allowed to hold a tool. It has nothing to say about whether this specific invocation, right now, is the one you meant to authorize.
What to check now that the agent already has admin tools
TL;DR: For the part of an agent's admin tools that reach your own infrastructure, scope which tools it can even invoke at connection time, check whether an in-flight action still fits the session's declared purpose, and keep one record of what actually ran. None of that touches what the agent can see inside your CRM or helpdesk—that stays the SaaS platform's job.
For the SaaS half—what your support agent can see of a customer's billing record inside Salesforce or Zendesk—that's the SaaS platform's job; Agent User or field-level security is a reasonable place to check it's configured. Alpacon has no visibility or control at that layer.
But for the part that reaches your own infrastructure—the webhook that fires an internal script, the internal API, a database call, an MCP tool wired to a production host—here's what execution-time control looks like, and what it's still narrow about:
→ Scope which tools the agent can even reach. alpacon-mcp's local mode takes a --toolsets flag, so an operator registers only the tool groups a given AI client should have, instead of exposing the full surface by default. It's a registration-time scope, not a per-call judgment, and local-mode only—GitHub's own MCP server ships the same flag, so treat it as table stakes, not a differentiator.
→ Weigh an action against the session's declared purpose. On Alpacon's exec lane, a command scoring in the grey zone is weighed by an LLM against what the session said it was for, not just the command text alone. Three limits, all real: exec lane only, not interactive Websh (a human-operator surface an agent doesn't use); grey zone only (roughly 0.3–0.8 on risk), so anything scored low skips this step entirely; and a vetted purpose can tighten the bar but never loosen it.
→ Grey-zone actions can route to a human before they run. A command the risk lane scores in the grey zone can be held for out-of-band approval—console or Slack, and the channel that made the request can't approve itself. A can, not an always: not every risky-looking action gets held for a human every time.
→ A governed channel's commands are judged and recorded, every time one runs. Across the command API, MCP, and OS-level sudo, when a tool call actually runs a command on a host, Alpacon judges and records it—not the fact that the tool exists or was registered. A tool call that issues no host command, like a settings read, isn't part of that judged surface. Direct SSH and service tokens sit outside it too.
None of this tells you what a Salesforce agent can see of a customer's record. But it does answer a narrower, different question—the one execution control is built to answer generally: once your agent's "admin tools" stop being SaaS objects and start being your own infrastructure, what actually checks the thing it's about to run.
The question worth asking about every admin tool you wired up
Before you add one more tool to what your support agent can invoke, ask which side of this line it's on. If it's a SaaS object—a Salesforce field, a Zendesk ticket, an Intercom conversation—the control point is identity and permission sets, and Agentforce's Agent User model is a reasonable bar to check against. If it's your infrastructure—a webhook, an internal API, a database, an MCP tool wired to a production host—the control point is what happens the moment it executes, and a permission set several layers up won't tell you anything about that. Most setups have both. Knowing which tool is which comes first, before either control can do its job.
| Access control | Execution control | |
|---|---|---|
| Answers | Is the agent allowed to hold this tool? | Does this specific use, right now, fit the session's purpose? |
| Checked | Once, at setup | Every time a command actually runs |
| SaaS-layer example | Agent User, Zendesk/Intercom admin gating | Not a SaaS-layer concept—lives in your own infrastructure |
| What DEF CON 34 exploited | Nothing—the access itself was legitimate | The missing re-check when the tool fired |
FAQ
Does giving an AI agent its own identity, like Salesforce's Agent User, fix the access-control gap?
It fixes the half about standing permissions—what the agent can see and touch inside that platform. It doesn't answer the question DEF CON 34 found exploited: whether the specific request firing a tool right now was the one anyone actually authorized. That's a runtime check, not an identity model.
Can Alpacon control what a Salesforce or Zendesk AI agent sees of customer data?
No. Alpacon operates at the infrastructure execution layer—shell, sudo, the command API, MCP tool calls reaching a managed host—not the SaaS application layer. What a support agent can see of a Salesforce record or Zendesk ticket is governed by that platform's own permission model, not Alpacon.
What's the actual difference between access control and execution control for an AI agent?
Access control decides whether an agent is allowed to hold a tool. Execution control decides whether this specific use of that tool, right now, fits what the session is supposed to be doing. Most admin-tool exploits, including DEF CON 34's, land in the gap between those two questions.
Does grey-zone approval mean a human reviews every risky action an agent takes?
No. It's scoped to actions the risk engine scores in a defined grey zone (roughly 0.3–0.8); anything scored lower never triggers the check. Grey-zone actions can route to a human—they aren't held for one every time.
Every tool your team wires an agent into eventually crosses that line. Knowing which side it's on—identity and permission sets, or a specific execution to check—is what decides whether the next admin tool you add gets the right kind of control at all.
