An AI agent is sitting on a workstation in your network right now. It has API keys, database passwords, SSH credentials. It can access internal systems, move laterally, and run tasks without audit trails. And probably nobody knows it's there, nobody owns it, and nobody has reviewed what it can actually do.

This isn't hypothetical. As productivity tools like ChatGPT, Claude, and local LLMs become commonplace, employees are spinning up autonomous agents to automate routine work. The problem is that these agents are treated as ephemeral, harmless utilities rather than as what they actually are: software processes with persistent access to sensitive infrastructure.

The Access Control Problem

Traditional insider-threat frameworks assume a human making deliberate choices. We audit user access, track privilege escalation, monitor database queries. When a person requests read access to a production database, security reviews it. When they try to enumerate API endpoints, logging catches it.

An AI agent bypasses this mental model entirely. Nobody thinks of it as a security subject because nobody thinks of it as a deliberate actor. It's treated as a personal tool, like a calculator or a text editor. Yet it often runs with the credentials of whoever deployed it, inheriting their permissions wholesale.

Worse, the agent may ask for permission once during setup, and the user clicks 'allow' without scrutinising what scopes it's requesting. An agent designed to 'help with reporting' might request read access to billing, employee records, and customer data simultaneously. The access sits there, potentially for months, until someone stumbles across a log entry or the agent is discovered during a random audit.

Credential Handling at Scale

For infrastructure and hosting operations, the risk multiplies. AI agents need to interact with APIs: cloud provisioning, DNS management, log aggregation, database administration. To do so, they store API keys, authentication tokens, and sometimes database passwords.

These credentials are often stored in plain text in a config file, in environment variables, or in browser cookies that the agent reads. If the workstation is compromised — through phishing, malware, or a supply-chain vulnerability — an attacker gains not just that user's access, but the access of every AI agent they've deployed. A DevOps engineer with a handful of agents might inadvertently hand an attacker keys to production databases, CDN configs, and billing systems.

There's also the question of agent-to-agent communication. If multiple agents are deployed on the same network, do they validate each other. Do they log their interactions. Or does one agent trust another agent without any cryptographic verification.

Audit Trails and Accountability

When an API key is used, who's accountable. The employee who deployed the agent, the agent itself, or nobody. Most logging systems don't distinguish between a human making an API call and an agent doing it. A query that deletes 10,000 records shows up in the audit log as 'user [email protected] ran this query'. But John didn't. A scheduled agent he deployed two months ago did.

This creates a liability gap. If something goes wrong — data corruption, misconfiguration, credential theft — it's unclear whether it was negligence, sabotage, or a compromised agent. The engineer claims they didn't touch the system. The logs show their credentials. The investigation stalls.

Proper accountability requires:

Moving Forward

The pattern is familiar from containerisation and microservices. When Docker first gained adoption, many teams deployed containers without thinking about image scanning, privilege isolation, or runtime policies. It took several years and painful incidents before container security practices matured. AI agents are at an earlier stage of that cycle now.

For infrastructure teams, the response shouldn't be to ban AI agents outright. They do provide genuine productivity gains. Instead, treat them as you would any other software running on your network: define ownership, audit permissions, monitor execution, and use strong authentication. If an agent had a human counterpart with the same access and no oversight, you'd fire them. Apply the same standard to your AI agents, and you'll close a gap that most organisations haven't noticed yet.