When an enterprise AI agent misbehaves, the first question people ask is what the model did. A contributed analysis published on The Hacker News on October 19, 2026, covering a chain first documented by security researchers in August 2026, argues that the question is aimed at the wrong layer of the stack. Most agents do not arrive as standalone systems. They arrive inside platforms the business already runs: Salesforce, ServiceNow, the CRM, the ERP. They inherit triggers, intake features, permissions and data flows that were designed years before any agent existed. The failure surface is the application around the agent, and the application is the thing nobody re-reviewed.
The chain an outsider can ride
In Salesforce Agentforce, the recommended way to make an agent respond to events is a Flow: a record is created or a case is updated, and the Flow passes data into the agent's prompt. Separately, Email-to-Case and Web-to-Case turn inbound customer messages into case records. That is how airlines and hotels run support intake. Both are standard, documented, as-designed features of the platform.
Chained together, they produce this route: public internet, to email, to case record, to agent prompt, to agent action, to case comment, to outbound reply. An unauthenticated outsider now has a path into an internal agent's instructions, and the agent's reply can leave through the same door. Nothing was misconfigured. That is the uncomfortable part.
A prompt filter watching the agent's inputs does not know that a particular input originated from a stranger, because prompt filters do not understand Email-to-Case. A vendor risk review performed once at procurement sees none of it, because at procurement the agent did not exist. Securing an inherited agent therefore means understanding its host application at the depth its own administrators do, and that depth is exactly what a questionnaire and an external scanner both lack.
Nobody procured these agents
The platforms have made agent creation about as accessible as making a slide deck. Marketing operations builds an agent to pull pipeline reports. Finance builds one to reconcile invoices. Each rides its creator's permissions, because that is what makes it useful. Shadow AI was an employee pasting data into a chatbot. Shadow agents are that employee's access, running unattended, multiplied across everything they were ever granted. This is the same unregistered-threat pattern we flagged in our earlier coverage of shadow agents and of CERT-In's finding that test agents reached production systems undetected.
Increasingly, agents also build agents. A coding agent tagged into a chat channel can scaffold and deploy another agent as easily as it opens a pull request. An orchestration platform spins up sub-agents to divide a task, each with its own connections and none with its own review. Any governance model that assumes a human requested each agent is quietly obsolete.
The City-Forum campaign, an active worldwide data-theft operation against Salesforce and ServiceNow instances documented since March 2025, was found in exactly this territory: the gap between platform features and the configurations enterprises actually run.
Why governance keeps producing a document
Ask a large enterprise about agent governance and the answer is usually a document: an acceptable-use policy, a monthly committee, a set of principles nobody disputes and nothing enforces. Ask the operational question: how many agents are running right now, what can they reach, and who owns each one? The document does not know.
The OWASP Agentic Skills Top 10 now describes the sharpest version of this gap under its "No Governance" category: a skill deployed and managed inside a third-party platform is unreachable by external scanners. The tools an enterprise points at the problem from outside cannot see inside the venues where most agents live. Governance fails most often because the rules get written before the security team can see the things the rules apply to.
The six-layer test
Here is the working order the October 19 analysis recommends, bottom-up, with an operational test at each layer. If a program cannot pass these tests, it is paper.
| Layer | What it has to produce | The operational test |
|---|---|---|
| Discovery | A continuously refreshed population across app configs, OAuth grants, network, endpoint, email metadata and browser | Is the discovered count several multiples of the list IT keeps? If not, discovery is not reaching where agents live. |
| Posture | Every platform's agent-relevant settings, measured against intended configuration | Can the team list the intake features and guest-user exposures wired to agent triggers on its top three platforms? |
| Identity and ownership | An identity and a named owner per agent, with a lifecycle | Pick an agent at random: does a human raise a hand within a day when asked whose it is? |
| Usage | Who is building what, through which surface, with what data | Is there a sanctioned path that ships a business team's agent with secure defaults, or only a block? |
| Agent controls | Least privilege against observed need, approval and quarantine for new agents, risk tiering by full context | Does the same finding on a sandboxed dev agent and a customer-facing one show different severities? |
| Runtime | Live inspection and intervention | Is it fed by the five layers above, or deployed first and enforcing blind? |
The cost of paper compliance
The EU AI Act's penalties carry GDPR-level weight: up to 35 million euros or 7% of global annual turnover for prohibited practices, and up to 15 million euros or 3% for other violations. GDPR already showed what happens when compliance exists on paper. British Airways was fined 20 million pounds and Marriott 18.4 million pounds not for having imperfect policies, since everyone has imperfect policies, but because compliance could not be evidenced operationally when regulators asked.
A governance practice built bottom-up generates that evidence as a byproduct: the inventory, the owners, the configurations, the review history. The Agentforce chain above is not an exploit. It is a configuration, and configurations are governable, provided someone can see them.
What to do this week
- List every entry point on your top three platforms where an outside message can become a record that feeds an agent: Email-to-Case, Web-to-Case, web forms, guest-user objects.
- Check which automations pass untrusted record data into agent prompts, and mark them for review.
- Name an owner for every agent you can find, and an escalation path for the ones you cannot.
- Hunt for agent-byproduct agents: sub-agents spawned by orchestrators or coding agents, with their own connections.
- Build in the order above: discovery, posture, identity, usage, controls, runtime. Runtime tooling deployed first enforces blind.
If the flow of agents through your platforms feels hard to track from the inside, that is precisely the problem this analysis documents, and the kind of visibility work we build for clients. You can reach us through the contact page.
Read next
