When a developer leaves your SaaS company, you revoke their Okta access, disable their GitHub account, and rotate API keys. But what happens to the AI agent they built last month, the one that still has standing access to your production customer database?
We've spent the past six months testing AI implementations for European B2B SaaS companies, and we keep seeing a pattern that should concern every technical founder: orphaned AI agents create persistent access paths that traditional security audits miss. This is not theoretical. We found production agents with full database access whose creators had left the company four to six months earlier.
Securing these systems takes a different approach than securing traditional software. AI agents don't just run code. They make autonomous decisions about what data to access and when.
The identity problem: AI agents don't show up in your IAM audit
Your identity and access management system knows about human users and service accounts. But does it know about the LangChain agent your backend engineer spun up to automate customer support ticket classification?
During AI red teaming engagements, we keep finding the same three gaps:
- Agents authenticate using developer credentials, not dedicated service accounts. The agent uses an API key tied to alice@startup.com, but Alice left three months ago. Her Slack is deactivated and her laptop is wiped, yet her API key is still active because it's embedded in an agent configuration file nobody documented.
- Agents receive broad permissions by default. Developers building AI features need to move fast. They grant database read access to prototype a feature, then never scope it down. The agent that was supposed to summarize support tickets can read every customer record in your Postgres instance.
- Agent activity looks like normal application behavior. Your SIEM sees API calls from a known service. It doesn't flag that the pattern has changed, that the agent is now querying customer data it never touched before, because someone modified its prompt or tool configuration. We test for this systematically. We ask teams to show us the documentation for every AI agent in production, and most can't produce it. Then we search codebases for LLM API calls and trace them to their authentication sources. The gap between the agents a team knows about and the agents actually running averages 40% in Series A companies.
Tool access creates lateral movement paths
Data access is only half the risk. The other half is what AI agents can do with that access.
Modern AI agents do more than answer questions. They execute functions: they query databases, call internal APIs, modify records, and trigger workflows. Every tool an agent can invoke is a potential privilege escalation path.
One example from a recent engagement. We tested a customer-facing AI assistant that could look up order status. The agent had a tool that called an internal API, and that API accepted an order ID parameter. The API never checked that the authenticated user owned that order. That's a classic IDOR vulnerability, hidden behind an AI agent's tool configuration instead of exposed in your API documentation.
The agent's creator had left the company. The API it called had been refactored twice. Nobody knew the agent existed until we chained prompt injection into unauthorized order access across tenant boundaries.
Another pattern is agents with access to code execution environments. We've found AI coding assistants that can write and run Python scripts with access to production secrets managers. The original use case was helping developers debug production issues faster. The actual risk is that an attacker who compromises the agent, through prompt injection or a leaked API key in an environment file, can run arbitrary code in your production VPC.
Standing privileges: the "just in case" problem
Developers build AI features under time pressure. They grant an agent access to five data sources because they're not sure which ones the LLM will need. The agent ends up using two. The other three permissions stay active indefinitely.
We call these standing privileges: access rights that stay granted just in case, long after anyone needs them.
During AI red teaming, we test whether agents follow least privilege:
- Can the agent access data outside its documented purpose?
- Does it retain access to resources it hasn't touched in 30+ days?
- Can we manipulate prompts to make it use tools it shouldn't? In one test, a RAG-based documentation assistant had read access to the entire company wiki, including pages on security architecture, API authentication flows, and internal service diagrams. The agent's job was to answer product questions for new employees. It didn't need the security documentation. Nobody had scoped it down, because the implementation was "just connect it to Confluence and let the LLM figure out what's relevant."
An attacker who reached that agent, through prompt injection or a compromised API endpoint, could extract your complete internal security posture with carefully crafted questions.
What SaaS teams should do right now
You don't need an enterprise identity governance platform to start. Five steps cover most of the risk.
Inventory your AI agents now.
Search your codebase for OpenAI, Anthropic, and Cohere API calls, then trace each one to its authentication method. Document who created it, what data it accesses, and what tools it can invoke. If you can't produce this list in a day, you have orphaned agents.
Give AI agents dedicated service accounts.
Stop using developer personal API keys, and rotate credentials when team members leave. This sounds obvious, but we find personal credentials in production AI agents in over 60% of engagements.
Audit tool permissions monthly.
Review what each agent can actually do, not just what it's supposed to do. Test whether you can manipulate it into using tools outside its scope, and remove standing privileges unused for 30 days.
Add agent activity to your security monitoring.
Log every tool invocation and data access. Alert on unusual patterns, such as an agent that suddenly queries 10x more records or reads data sources it has never touched. Treat AI agent activity as high-risk authentication, not routine application traffic.
Test every tool-enabled agent for prompt injection.
If your agent can execute functions, assume an attacker will try to manipulate it into calling them maliciously. We find exploitable prompt injection in roughly 70% of the tool-enabled agents we test.
What this means for your team
- AI agents don't inherit your existing security controls. They need explicit identity management and access policies.
- Orphaned agents outlive their creators unless you have a process to inventory and decommission them.
- Tool-enabled agents create privilege escalation paths that traditional penetration testing won't find.
- Standing privileges compound. Agents accumulate access they don't need unless you actively scope them down.
- Agent activity needs dedicated monitoring. Existing SIEM rules won't catch AI-specific abuse. SaaS AI agent security is its own discipline, not a bolt-on to application security. It calls for testing autonomous behavior, tool abuse, and identity lifecycle management that most teams haven't built yet.
At Faultline Security, we test for these risks through AI red teaming engagements that map your AI attack surface, identify orphaned agents, and check whether your agents follow least privilege. If you're running AI features in production and haven't tested for agent security risks, get in touch.
