Back
Securing Agents in Production
James Chainey
AI Ecosystem

Securing Agents in Production

How to Meet Your Compliance & Regulatory Needs when Running AI Agents with Runloop

Compliance & Security Aren’t Optional

The Harvard Business Review identified Cybersecurity & Privacy challenges as the single biggest roadblock to successful AI adoption by organizations. As a consequence, despite promising pilot programs, many enterprises find themselves unable to adopt agentic workflows in production. Almost all medium-large scale organizations need some level of compliance with general purpose regulations like SOC-2, ISO 27001, and GDPR.

Companies operating in highly regulated environments must meet a much higher level of regulatory burden. If you work in finance or health care, then your company simply doesn’t have the luxury of moving fast and breaking things. There is a notoriously high bar for organizations needing to meet compliance standards for programs like:

  • PCI-DSS
  • HIPAA
  • NYDFS
  • CCPA / CPRA

What that means for companies running AI agents has been uncertain at best. Fortunately, Runloop’s got you covered.

In this article we’ll cover some of the security & compliance features in Runloop. Using the platform, you can run an AI agent with confidence, knowing that your regulatory needs are satisfied. We’ll also cover Runloop’s internal compliance and security posture and talk about how this influences our product development. Finally, we’ll talk about deploying Runloop to your cluster via Deploy to VPC: ideal for customers needing the highest level of data protection.

“Trusted Agents” Don’t Exist

“Trusted computing” was the tech industry’s first attempt at ensuring holistic security across a large attack surface. The basic idea was to ensure that every link in a chain of systems should be secure and reliable. Once trusted, each component in the trust ring often had the power to take arbitrary actions. “Trusted computing” ultimately fell out of favor with the security community because there was a critical flaw in the approach: if any single link in the trust chain became compromised, the entire trust ring was compromised.

Trusted computing ultimately expanded the attack surface that needed to be secured and introduced dependencies on third parties that weren’t always incentivized to maintain the same, tough security posture as other links in the trust chain.

With the arrival of agents, Trusted Computing is enjoying somewhat of a resurgence. The concept of a “Trusted Agent” follows fundamentally the same approach to security — and is flawed for the same reason. It’s simply not possible to get agents to self-regulate using prompts or using training to coach the behavior you want:

  • Prompt injection remains a real problem.
  • Secret exfiltration remains a real problem.
  • Unregulated network access remains a real problem.

None of these problems can be solved at the agent level. This is because the agents themselves are inherently untrustworthy actors. The right security posture to assume, therefore, is that the agent is always compromised. This may sound familiar: this is the essence of zero trust applied to agents; and it’s exactly what succeed Trusted Computing.

Zero Trust Computing for Agents

So what does it mean for an agent to operate in a zero trust environment? In essence, it means the same thing for an agentic system as it does for any other system. Encryption at rest & encryption in transit are obvious needs, and so too are restrictions on which network endpoints are accessible and in what capacity. Similarly, secrets must be protected and rotated frequently. If credentials are lost, they need to be instantly replaceable.

Strong Isolation

If security is important to you, you should be aware that not all sandbox providers offer strong isolation of resources. Isolation isn’t just about CPU and memory quotas. It’s about ensuring there are no backchannels to your data. Runloop offers secure resource isolation at every level:

  • Compute and data are physically partitioned at the account level.
  • What you see is what you get: the machine cannot access resources from neighbors and cannot use system swap.
  • Network access within the cluster is blocked by default, with fine-grained networking controls available.

In regulated environments, those details matter. When you evaluate sandbox providers, you should ask how deep the isolation guarantees actually go.

Fine-Grained Network Access Control

Using Network Policies you can restrict ingress and egress traffic by hostname, protocol, and port with wildcards. This means you can grant your agent read-only access to a resource while preventing it from using destructive endpoints or destroying your inbox.

Credential Protection

Most systems are built to protect against credential theft from malicious external actors. Agent Gateway & MCP Hub protect credentials from internal actors, including your own agents. They work by substitute credentials at the proxy layer, so API keys never enter the runtime environment. The agent receives temporary gateway tokens, and every outbound request is evaluated against policy before it leaves the sandbox. If an agent is compromised, its blast radius is strictly bounded by infrastructure; not by prompts.

Authentication is therefore enforced at the infrastructure layer by preventing agents from ever accessing raw credentials. This means an agent can be constrained to:

  • Read-only access to a specific endpoint
  • Access to a single third-party API or MCP service via a single controlled gateway
  • Tightly scoped internal services

Secret Management

The secrets used by Agent Gateway and MCP Hub are fundamentally still protected secrets: the proxies simply use them in a protected fashion. Secrets stored in Runloop use envelope encryption. This means that there is a per-secret Data Encryption Key (DEK) and the keys themselves are encrypted using a Key Encryption Key (KEK). This provides secure, scalable credential management.

Full Data Sovereignty & Deploy to VPC

Some organizations cannot allow agent workloads, or even their execution environments, to run outside their controlled network boundary. For these customers, Runloop offers Deploy to VPC. This may be a regulatory need: data ingress and egress are sometimes impacted by export laws. More generally, most customers that need full data sovereignty or that cannot afford to run in a multi-tenant environment will need an execution platform that resides inside their network boundary. 

Deployment to VPC offers the same security guarantees as our hosted agent orchestration and execution platform, but the data plane resides entirely in your cluster. For regulated enterprises, this may be the crucial component that makes agents usable in production.

Compliance & Regulatory Requirements for Agents

Security and compliance breaches can result in regulatory and even criminal enforcement. Nobody wants to go to jail because their agent leaked their API keys to a rogue lobsterbot, but without adequate safeguards, it’s only a matter of time until this happens. Don’t let it happen to you!

If your company is serious about security, Runloop is a key component of that policy. Running agents in production isn’t a problem that’s specific to agents. There are well known patterns and best practices that already exist inside the industry.

Don’t treat agentic security as a prompt engineering problem: it’s an infrastructure problem. Strong isolation prevents cross-tenant leakage. Fine-grained network controls bound outbound risk. Secret management and credential substitution eliminate key exfiltration. Finally, Deploy to VPC offers the very strongest security posture, ensuring that your data never leaves your network at all.

Zero-trust isn’t a marketing slogan. It’s an architectural and infrastructure decision. Runloop makes that decision easy.

Interested in finding out more? Contact sales@runloop.ai today.

Need help getting started? We’re available at support@runloop.ai.

We can’t wait to see what you’ll build.