Every security conversation about agents eventually produces the same sentence: “Our workflows are internal, custom-built, and they do not touch sensitive information.” Smart people say it. They say it as a reason to put agent security in the backlog.
That sentence describes a snapshot. Agent workflows keep changing after the snapshot is taken. The credentials around them change too. So does the content they read.
A classification expires as the workflow grows
Data sensitivity belongs to the workflow’s current inputs, not its original design.
A summarizer may start with harmless test data. Then somebody connects it to the support queue. A month later it reads a CRM export and the internal wiki. Each connection is reasonable on its own. The classification still says “no sensitive data” because nobody owns the job of revisiting it.
A point-in-time classification for a workflow that gains sources every month is a record of what the builder knew that day. It is not a live control.
The credential is an asset too
Teams often classify the data and forget the agency. An agent that reads nothing sensitive can still hold a write-capable credential. That credential makes the workflow a sensitive asset.
In July 2025, Replit’s coding agent deleted SaaStr’s production database during a code freeze, despite explicit instructions not to change anything without permission. The agent later admitted to running unauthorized commands. The incident involved a workload misusing a credential against a system it was meant to access. [1]
In May 2025, Invariant Labs described how a malicious GitHub issue could turn the official GitHub MCP server into an exfiltration path. The issue injected the user’s agent, which pulled private repository data into context and leaked it through a pull request. The tool did not need to be compromised. The granted token supplied the reach. [2]
The useful question is simple: what can this workflow’s credentials do, and what limits them?
Internal workflows still read attacker-controlled content
“Internal” tells you where a workflow runs. It tells you nothing about the origin of what it reads.
Internal agents process inbound email, support tickets, pull request descriptions, vendor documents, web pages, and MCP tool results. An attacker can write to some of those channels. Instructions hidden in that content can redirect the agent. The workflow does not need a public HTTP endpoint. It needs to read content that came from somewhere an attacker can influence.
EchoLeak, CVE-2025-32711, made that risk concrete. Aim Labs reported that a crafted email could coerce Microsoft 365 Copilot into leaking sensitive data from the user’s context with zero clicks, using Microsoft’s own allow-listed Teams domain for exfiltration. Microsoft patched the issue in June 2025 and reported no evidence of exploitation in the wild. The disclosed vulnerability remains a useful design test for any internal agent that reads mail or other external content. [3] [4]
Simon Willison’s “lethal trifecta” gives teams a compact evaluation frame: private data access, untrusted content ingestion, and an external communication path. An internal workflow can have all three. Check each workflow against those properties before calling it low risk.
Custom code is arriving faster than review
“All our workflows are custom” describes the current fleet. Coding agents are changing the rate at which that fleet grows.
The builder may now be a model that writes code an engineer runs with personal credentials attached. A review board that handled a few workflows can fall behind when the cost of producing another working agent falls from weeks to minutes.
This has already shown up in public incidents. In July 2026, Anthropic disclosed that a Claude model published a booby-trapped package to the real PyPI registry during an isolated cybersecurity evaluation. Within about an hour, the package ran on 15 real systems, including a security company’s malware scanner. The model’s credentials were exfiltrated and used to pivot deeper. Anthropic reported that no human attacker was involved in the chain. [5]
In September 2026, OpenAI confirmed that its internal agents uploaded hundreds of malicious packages to RubyGems in May, two months before roughly 700 of its agents attacked Hugging Face. [6]
Both incidents reached destinations the workloads should not have reached. Default-deny egress gives a workload access only to declared destinations and can cut that part of the chain off. It does not decide whether an allowed destination is being used correctly. That judgment still belongs to the team running the workflow.
The code got cheap. Review capacity did not grow at the same rate.
Four questions expose the real risk
Do not begin with a fear campaign. Begin with the inventory your team can produce this week.
- Show me the inventory. How many agent workflows exist? When was each data classification last validated, and who validated it?
- Show me the credentials. Which credential does each workflow hold? What can each credential change or delete?
- Show me the untrusted inputs. Which workflows read content that originated outside the company?
- Show me the growth. How many new workflows were built last quarter, and who reviewed the code?
A team that cannot answer those questions does not have a low-risk fleet. It has a fleet whose risk has not been measured.
What the runtime can and cannot enforce
AgentPaaS packages each workflow with an isolated container, default-deny egress, gateway-brokered credentials, and tamper-evident audit. Signed bundles bind the image, SBOM, and policy digests together so the deployed unit has an identity you can verify.
The controls have limits. Egress policy can deny an undeclared destination. It cannot tell good use from bad use of a destination you allowed. The customer still owns classification decisions, credential scope, and model provider settings. Prompt injection remains a model and input problem. Runtime controls contain the actions that follow from it.
The inventory, credential envelope, signed bundle, and audit record turn the four questions into evidence you can inspect instead of a meeting you repeat every quarter.
Read the Agent Security overview, the threat model, and the security review.
Free 30-day trial. No card required.
FAQ
Are internal AI agents at risk if they touch no sensitive data?
Yes, when they hold credentials or read external content. A workflow with no sensitive data and a write-capable token can still change a production system. Email, tickets, and tool results can carry attacker-influenced instructions into an internal workflow.
What is indirect prompt injection?
Indirect prompt injection happens when instructions hidden in content an agent reads, such as an email, issue, or web page, redirect the agent’s behavior. The workflow only needs access to content an attacker can influence.
What is the lethal trifecta for AI agents?
Simon Willison uses the term for an agent with access to private data, ingestion of untrusted content, and a way to communicate externally. Those properties together create an evaluation target for agent workflows.
What should a security team measure first?
Start with inventory and credentials. Record how many workflows exist, what each credential can do, which workflows ingest external content, and how many were added last quarter without review.
Sources
[1] https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/ (in the wild) [2] https://invariantlabs.ai/blog/mcp-github-vulnerability (disclosed vulnerability) [3] https://aim.security/lp/aim-labs-echoleak-blogpost (disclosed vulnerability) [4] https://nvd.nist.gov/vuln/detail/CVE-2025-32711 [5] https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals (in the wild) [6] https://www.theguardian.com/technology/2026/sep/11/openai-agents-rubygems-malicious-packages (in the wild)