Expanding your attack surface isn't the price of an AI agent. It's an artifact of how you wire it in—and it's avoidable.
I gave a version of this argument at the Agentic AI Security Summit in Seoul earlier this year, and the room kept snagging on the same question: does adopting AI agents have to widen your attack surface? After a few years building an execution-control layer for exactly this, my answer is no—and the reason is worth walking through.
Here's the pattern I keep seeing. Adding an AI agent to production usually ships four things you didn't ask for: a new identity, a new key, a new standing credential, and a new inbound path nobody governs. None of them are the agent itself. They're how it got connected—and most teams treat that as the unavoidable cost of adopting AI.
It isn't. Expanding your attack surface is not the price of an AI agent. It's an artifact of how you wire it in. Put the agent on the same governed path your humans already use, and you add the capability without the exposure.
Do AI agents increase your attack surface?
TL;DR: Not inherently. The exposure comes from how most teams connect an agent—a new identity, a standing key, a new inbound path—not from the agent itself. Connect it through your existing governed access path and it adds no net-new attack surface on that path.
When an engineer stands up an agent to operate infrastructure—an incident responder, a deployment bot, a coding agent with shell access—the quickest path is to give it credentials. A service account. An SSH key in a secrets manager. A broadly scoped API token, because scoping it tightly is tedious and the agent "needs to be able to do things."
Each of those is a new, long-lived, high-value target. And unlike a human, an agent's credential lives in automation—copied into a pipeline, referenced in a config, held by a process that never sleeps and never gets offboarded. Worse, it multiplies: one agent template spins up hundreds of identical sessions, each carrying the same standing credential. You haven't added a user. You've added standing privilege, at scale, that nobody is watching in real time.
The numbers say this is already the norm
TL;DR: Most organizations already can't see their own agents—82% report unknown AI agents—and machine identities outnumber humans by as much as 144 to 1 in cloud-native/DevOps. The controls most teams trust don't see the agent problem, because every action the agent takes is authorized.
Machine identities already vastly outnumber humans—some industry counts put it as high as 144 to 1 in cloud-native and DevOps environments. Most teams answer their first production agent by making it number 145: one more token, one more key, one more account to leak or forget. And most aren't governing it—78% of organizations have no formal policy for creating or removing AI identities, and 92% aren't confident their legacy IAM can manage the risk.
The scale is already past oversight: 82% of organizations have unknown AI agents in their environment, and 65% have had an AI-agent-related incident in the past year. At RSAC 2026, attendees named agentic AI the top emerging attack vector, and 60% said they couldn't reliably terminate a malfunctioning agent; 63% couldn't enforce what an agent is allowed to do.
And when one of those standing credentials leaks, the clock isn't on your side. Leaked credentials get scanned, escalated, and exfiltrated at machine speed, while the average breach still runs 194 days before anyone identifies it (IBM Cost of a Data Breach 2024). "Read-only" doesn't save you either—read access alone still leaks secrets, configs, and topology.
Here's what makes this an execution problem, not an access problem: in the agent intrusions security teams are now documenting, every action in the chain is authorized. The agent logs in with real credentials and runs real commands. There's nothing malicious for IAM, EDR, a WAF, or a VPN to flag—because from their vantage point, nothing malicious happened. The controls worked. The data still walked out. (We walked through one such incident in detail: the gate authenticated the session, the vault returned the secret, and the database was dumped anyway.)
Where does the exposure actually come from?
TL;DR: From connecting the agent outside your governed path—as a new privileged actor with its own identity, key, and inbound route. Put it on the same path as a human and "adding an agent" stops meaning "adding surface."
The exposure doesn't come from the agent's intelligence. It comes from bolting the agent onto your infrastructure outside the path you already govern—as a brand-new privileged actor with its own identity, its own key, and its own unwatched route in.
So the fix isn't a new product to watch the new surface. It's to not add a new surface. Route the agent through the same path a human takes—same identity model, same access decision, same audit trail—and "adding an agent" stops meaning "adding exposure." It means adding one more session to a pipeline you already run.
Concretely, that looks like this. When an agent needs to act, it doesn't get a key—it opens a scoped session and waits for approval:
$ alpacon work-session create \
--requester-type agent \
--purpose "fix nginx 501" \
--server staging-web \
--scope command,sudo \
--sudo "systemctl reload nginx" \
--expires-in 1h
✓ session created · pending approval
✓ scope: staging-web · [command, sudo]
✓ audit: streaming →
One server. One sudo command—declared up front—and a one-hour ceiling. Because the session is flagged as agent-driven, it routes to a human for approval instead of activating on its own; every action streams to the audit log; and when the hour is up, the access is gone. No SSH key changed hands, and nothing about that agent outlives the task. That's the idea behind Alpacon.
How do you add an agent without adding attack surface?
TL;DR: Keep four things the same as your human access path—identity, keys, network direction, and privilege—so the agent inherits your governance instead of opening a new gap.
Four things stay the same when the agent goes on the human path—which is exactly the point.
The agent isn't a new identity. In Alpacon, every action on infrastructure belongs to a Work Session—there is no out-of-session path. An agent doesn't get its own identity silo; it operates under an existing user or application identity, distinguished only by a flag marking it as an agent rather than a person. You don't stand up a parallel access path, credential store, or audit stream for it. Its blast radius is bounded to what its session declared.
There's no new key to steal. Alpacon binds identity to the system directly—an Alpacon IAM identity is the system identity, provisioned on first access and removed when the identity is deprovisioned. There's no long-lived SSH key parked in a vault for the agent, which means there's nothing to exfiltrate from one. (Service tokens for CI/CD are the exception—they're long-lived, but the trade-off is that everything the token is allowed to do has to be defined up front as a fine-grained access list: which servers, which scopes, which sudo commands. So this is about eliminating standing keys and vaulted secrets on the access path, not about having zero credentials anywhere.)
There's no new inbound port. This is the mechanism that keeps your surface flat as the fleet grows. The usual way to give an agent a route in is to open one—SSH on port 22, a database port, the Kubernetes API—and expose it, often straight to the internet. Alpacon inverts it: the Alpamon agent on each host makes an outbound TLS connection to the control plane, so nothing on the host listens for inbound traffic, and access to a shell, a file, or a port—a database, an API—reaches it through a scoped tunnel over that one outbound channel. The host stays closed no matter how many agents connect, and the surface stays fixed instead of scaling with the fleet.
There's no standing credential to inherit. Authority in Alpacon is never ambient. It's reconstituted per action from what's observable—the session's declared scope, the assessed risk, proven human presence—not granted standing because of who the actor claims to be. A session without sudo in its scope is denied sudo before any prompt, even for a superuser. Agent-mode sessions are human-approved at creation and can't self-authorize an escalation, no matter how many tokens they hold. (One honest caveat: closing standing privilege on every credential type, including superuser API tokens, is still in progress—not finished across the board today.)
One caveat worth stating plainly: this governs the agent's path to your servers, not the agent's own runtime. A prompt-injected or compromised model is a real risk—it's just a different one. What this design guarantees is that a compromised agent inherits no new privileged route into your infrastructure beyond the governed one you can see, scope, and cut off.
Before you connect an agent: four questions to ask
TL;DR: For any agent—Alpacon or not—check identity, keys, network direction, and privilege. If each lands on the governed side, you've added capability, not attack surface.
You don't need Alpacon to pressure-test your own setup. Ask these before you wire the next agent into production:
- Identity—does the agent get its own new identity and credential store, or does it run under an identity you already govern?
- Keys—does it need a long-lived key or secret parked somewhere, or is access keyless and bound to identity, provisioned per session?
- Network—does connecting it open a new inbound port, or is the connection outbound-only so the host stays closed no matter how many agents connect?
- Privilege—does it hold standing access across servers, or a scoped, expiring, approved envelope per task?
If your answers land on the first half of each, you've added attack surface. If they land on the second, you've added capability. Alpacon is built so every answer lands on the second by default—and getting there starts with a lightweight host agent, not a rebuild of your stack.
The question most teams ask about production agents is "how do we monitor the new attack surface?" The better question is "why did we add one?" Adding AI capability and adding security exposure are two separate decisions—you only have to make the first.
Keeping the surface flat is only the first question. The next is what the agent does once it's in—a valid session is no help if the agent runs a command on a path it was never scoped for—and the one after that is whether you can prove what happened when someone asks. Those are the next two posts: just-in-time authority for agents, then audit that answers who, why, and with whose approval.
FAQ
Do AI agents increase your attack surface? Only if you connect them outside your governed access path—by giving them a new identity, a standing key, or a new inbound route. Route the agent through the same scoped, keyless, audited access your humans use and it adds no net-new attack surface on that path.
How is AI agent access different from human access? Functionally, it shouldn't be. The agent should be the same access primitive as a human—a scoped, time-bounded session under a governed identity—flagged as non-human so it gets more scrutiny, not a separate path with less.
Should an AI agent have its own SSH key? No. A long-lived SSH key for an agent is a standing, high-value credential that lives in automation and multiplies across sessions. Prefer keyless access bound to identity, provisioned per session and revoked when the identity is removed.
Can you audit what an AI agent did on a production server? Yes—if every agent action runs inside a session that records who or what acted, under what scope, with whose approval, on a single timeline. Command logs without that context aren't an audit. (More on that in a follow-up post.)
If you're wiring agents into production infrastructure, this is the layer that decides whether "adding an agent" means "adding exposure."
