What are your vendors' AI agents running on your servers?

Your employees aren't the only people logging into your servers. Engineers from maintenance providers, managed service providers (MSPs), outsourced development teams, and on-premises software vendors log in too. These vendors have started using AI in their work. If you've given their engineers keys and accounts, the AI agents they use can run commands on your servers with those same keys.

If your security or operations team is responsible for your company's servers, this article is for you. It examines what changes when a vendor's AI can reach those servers, how far your existing key management, approval processes, and PAM go in stopping it, and how you can control what outside people and agents run.

Vendors' AI is already in operations work

In an April 2026 survey by Kaseya, an IT management software provider for MSPs, 53% of more than 1,000 MSPs worldwide said they use AI to automate ticketing, patching, and monitoring. With agents reading logs, narrowing down causes, and handling repetitive tasks, a vendor's existing team can support more customers.

For your team, the concern is how those agents connect. If they use the keys or accounts you gave the vendor, you can't distinguish a person's work from an agent's. Engineers may also use personal agents outside their company's approved tools, so even the vendor may not know which agents accessed your servers. Agents run far more commands, far faster than people do, which makes it hard to reconstruct what happened from records alone afterward.

Your security team now needs to know how vendors' AI connects and what it runs. Security platforms such as Vanta have added AI questions to vendor security questionnaires. But a questionnaire gives you the vendor's answers. You still need a way to verify what actually ran on your servers (the runtime questions to add). Without that visibility, you're left with two options: ban the vendor's AI or allow it without knowing what it does. A ban means giving up the speed AI could offer, and it's still hard to verify that the vendor complies.

Three ways to manage access, all built for people

Outside access is usually managed in one of three ways. All three were built for people logging in.

Give the vendor a key. During setup, you open a port and hand over an admin account's SSH key. The vendor uses it to connect for outages and routine maintenance. Issuing an account and getting approval for every job is cumbersome, and you trust the vendor. But with an admin key, even reading a single log file means connecting with enough privilege to change the entire server. Each new vendor adds more keys held outside your company. Those keys may be shared inside the vendor and staff may change without your knowledge, and no record captures what ran after login. Could you name everyone at your vendors who holds an admin key to your servers?

Require approval for each job. Companies with strict security requirements review and approve a vendor's change request, then issue an account and VPN access for that job only. This is especially common in finance and government. Security certifications and regulations also emphasize account removal, approval for remote access, time limits, and work records. But when a service goes down at 2 a.m. and the vendor can't connect until approval clears, "just this once" exceptions appear. Temporary accounts that aren't revoked become standing access. The wait adds to your outage, and the records cover the plan and its approval, not the commands the vendor actually ran.

Adopt PAM. Privileged access management (PAM) products manage these steps in software. They centralize access, store passwords and keys, limit access by time and scope, and record sessions. Traditional PAM products such as CyberArk, BeyondTrust, and Delinea developed around centralized key storage and automated rotation. Imprivata offers products specifically for vendor access. Modern PAM products such as Teleport and StrongDM focus on access for internal teams. These products can resolve much of the problem of shared accounts and keys handed to vendors. But deployment and operation often require a separate project. Where they block commands before execution, they generally rely on predefined rules. The same command can be necessary for one job and risky for another, a distinction rules alone struggle to make.

AI agents make the limits of all three approaches more pronounced. They can use the keys you've handed over, approval processes can't keep pace with the commands they send, and session recordings exceed what a person can review.

Incidents grow from access that's too broad or kept too long

These gaps show up in real incidents.

In late 2024, PowerSchool, a US education software company, was breached through a single account on its customer-support portal. The portal allowed support staff to access customer databases for maintenance and at the time didn't support multi-factor authentication. A vendor's account provided access to its customers' data.

In April 2026, security firm Huntress reported an attack that abused an MSP's remote-support tool. The attackers used the tool's high-privilege account to install remote-access tools on a domain controller. The incident resulted in 78 businesses having their systems isolated, and the attack went on to four of the MSP's customers. Huntress assessed that the series of attacks targeting this tool likely exploited a known vulnerability.

At Coupang, an e-commerce company whose main market is South Korea, a former employee took the signing key for an authentication system they had managed and used it to access user data. According to the government investigation published in February 2026, more than 33 million records of user information were leaked. The system and process for rotating keys when employees left were inadequate. The key's history wasn't tracked, so its use for other purposes couldn't be detected. This involved an insider rather than a vendor, and a different type of key from a server login. Even so, a key that stays valid after its holder leaves, with no way to trace its use, is the same problem a key handed to a vendor can create.

The entry points differed, but the incidents had a common pattern. One vendor support-portal account provided access to customer databases, one vendor's remote-support tool affected dozens of businesses, and a former employee's key remained valid. Verizon's 2026 Data Breach Investigations Report found third parties involved in 48% of breaches, up sharply from 30% the previous year. Add AI agents to the people using a vendor's accounts and tools, and the same paths get used faster and more widely.

When an incident happens, your company has to answer for it. Executives, auditors, and regulators ask: "Who was logged in at the time?" "What did they run?" "Who approved that work?" Relying solely on logs and explanations from the vendor makes it harder to establish the cause and extent of the damage.

The one question for the server owner

A vendor's questionnaire responses and explanations aren't enough. Your team needs to answer one question.

"Can you give outside people only the access their job needs, assess the commands their agents send against that purpose before they run, and see the execution record for yourself?"

That takes five things.

1. Assess an agent's commands against the job's purpose before execution. The same command can be necessary for one job and risky for another. Use the session's stated purpose as well as predefined rules to assess commands before they run, and route those that need human review to an approver.
2. Require agents to follow the same access process as people. Agents shouldn't borrow a vendor engineer's keys or account. They should use the designated access path and process, so their work goes through the same approval and is recorded alongside people's work.
3. Grant least privilege, and check people's work and agents' commands differently. Reading logs doesn't require permission to change the entire server, and not every command needs human approval. You can limit people's work to the approved job and scope while checking the commands agents send one by one.
4. Grant access for each job instead of handing over keys. Instead of holding an admin key, a vendor engineer states which servers they need, what they plan to do, and for how long, and receives access for that job.
5. Keep the execution records yourself. After the job, you should be able to see who connected, why, what ran, and who approved it without asking the vendor.

The process also needs to be easy to use. Avoiding the effort of granting access for every job is why the key was handed over in the first place. If requests and approvals are much harder than connecting with a key, "just this once" exceptions will return. Not every server needs the same approval process. For lower-risk servers, stating the job's purpose may be enough to connect, while important servers handling payments or personal data can require approval.

Meeting these requirements gives you less reason to ban your vendors' AI. When a vendor proposes using agents, you can set the scope of their work instead of debating a ban. When auditors ask about outside access, you can answer with records you hold. Your security team can review approval requests and completed work rather than watch every task.

How Alpacon answers the question

Alpacon is an execution control layer for people and AI agents working on servers. It grants access for each job, records commands run through Alpacon, and requires human approval when needed.

• Agent commands are assessed by rules and AI before execution. Agents submit commands through Alpacon Cloud's API or MCP (a standard protocol for connecting AI agents to external tools). Commands go through rules first. When the rules can't resolve a command, AI assesses it against the session's stated purpose. A command judged to need human review can be routed to an approver before execution. Approval takes place in the web console, separate from the channel that submitted the command, or in Slack if the workspace enables it (Essentials and higher). In Alpacon Cloud, an agent's CLI or API token can't approve its own request.
• Access starts with a session for each job. Rather than holding a key, the vendor's engineer or agent identifies themselves and requests a session (a unit of access with a stated purpose and scope). If approval is required when a session is created, a session the vendor requests opens only after someone on your side approves it.
• Each session has a privilege ceiling. By default, expanding the scope during a job requires another approval. On servers where Alpacon governs sudo, each use of sudo through a server account linked to an individual engineer is checked against the session's scope.
• You keep the execution records. Commands run through Alpacon appear on the session timeline along with the session's stated purpose. Who approved is recorded separately, in the approval history available to workspace admins on Essentials and higher.
• Direct access that bypasses Alpacon can also be detected. If external-access detection is enabled, direct SSH logins are identified as connections that bypassed Alpacon. Detection covers only login-based access from the moment it is enabled, and it doesn't block access, so you still need to revoke keys already given to vendors.
• No inbound port to open. The Alpacon component on each server connects outbound only, so you don't need to open an inbound network port.

This doesn't require a person to approve every change. Command-level checks apply when an agent's API or MCP call runs a command on a server, and only commands flagged for approval go to a person; engineers' work is managed through session approval and scope. These two mechanisms let you choose what to control directly.

Integrations that run outside sessions need separate management. An integration using a service token doesn't open a session or go through session approval; it runs within the permission list an admin approved when the token was issued. Which tokens to give a vendor, and with what permissions, is a separate decision from sessions.

Keeping control also depends on configuration. Your company owns the workspace, the unit in Alpacon that groups servers and users. Only your security and operations staff receive approval rights, and vendor accounts are used only to request sessions.

What the new process looks like

At 2 a.m., an alert reports that your payment service is responding slowly. An outside vendor operates the service.

Under the current process, the vendor's engineer either connects using the key you provided or submits a change request and waits for approval and an account. Either way, the next morning you get little more than a message saying "fixed."

The new process still requires an access request and approval. What changes is the effort involved and the records you keep afterward.

The vendor's engineer requests a session with a single line: "investigate payment service latency." The on-call member of your security team reviews and approves it in the web console, or in Slack if your workspace has enabled it on Essentials or higher. Once approved, the session opens with the scope set for this job.

The vendor assigns root-cause analysis to an AI agent, which requests a separate session for the same purpose. By default, a session an AI agent requests needs a person's approval, so your approver reviews that request too. While the agent reads logs and finds that the disk is nearly full, the vendor's engineer reviews the findings and decides what to do next. If the agent tries to delete old log files and the rules and AI judge that a person should check it, the command can be routed to your on-call approver before it runs. The approver reviews the request and decides.

The next morning, you have records to review. The session record shows which of the vendor's people connected, for what purpose, and what ran. On Essentials and higher, the approval history shows who approved the work.

Signs it's time to look again

If you work with one vendor, give them access to few servers, and handle no sensitive data, your current process may be enough. These situations are reasons to review how outsiders access your servers.

• You can't list which vendor personnel hold keys or accounts for your servers
• A vendor proposes automating operations with AI agents, or you learn it already uses them
• An audit or regulator asks for outside access approvals and work records
• You request an execution record after an incident but receive only the vendor's explanation
• You're renewing a contract or giving a new vendor access to servers handling payments or personal data

You don't need to change every vendor's access at once. Start with the vendors and servers where these situations apply.

Seeing what runs comes before deciding whether to block

Each company decides whether to allow its vendors' AI agents. That decision should be based on what actually ran on your servers. With your own view of the commands the vendor's people and agents executed, you can move past relying on the vendor's explanation and debating a ban, and decide how much work to entrust to them.