When the NSA, CISA, the FBI and four international partners published joint guidance on deploying AI systems securely, one theme ran through it: you have to be able to see and control the environment your AI runs in, with logging and monitoring you operate, not logging you are shown. That is hard to achieve when the AI, your code and your credentials all live in a vendor's cloud.
Most AI coding agent platforms are built that way. Your repository, the secrets the agent uses, and the traffic it generates pass through infrastructure someone else runs, and the record of what happened is a dashboard that vendor chooses to show you. For a regulated team, that is not a logging strategy. It is a trust assumption, and auditors do not accept trust assumptions.
Marshal is built the other way around. It installs into your own Kubernetes cluster, keeps secrets in your own key manager, and writes every audit record to a bucket you own. Nothing about the enforcement boundary depends on trusting us, because the enforcement boundary is inside your boundary.
This post explains how that works, at the level the public site describes it.
In-VPC was the starting point, not an add-on
Some products run in a vendor cloud and later bolt on a "self-hosted option" that reproduces part of the behavior. The ordering matters, because it shows in the trust model.
Marshal was designed to run inside your boundary first. The point of the whole system is that your code and your credentials do not leave your control to be governed, so governing them from someone else's cloud would defeat the design. Running in your VPC is not a deployment flavor added for enterprise buyers. It is the reason the security argument holds: no code and no secrets cross your boundary for an agent to use them, because the agent runs on your side of it.
What you install
You install Marshal with Helm into a Kubernetes cluster you run. The public site names the supported targets: GKE, EKS and k3s. Communication is over HTTPS.
Architecturally, and only at the level the site already shows, Marshal runs as a small set of planes in your cluster: a control plane that holds policy and brokers access, the isolated Spaces where agent sessions actually run, and the enforcement path that every agent request passes through. The relevant property for a platform team is ordinary: it is a Helm install into your cluster, running on compute you already operate, behind your own ingress.
Where secrets and audit records live
Two choices define the trust boundary, and in both the answer is "yours."
Secrets live in your own key management. Marshal integrates with your KMS or Vault rather than storing credentials in its own store, so the material an agent authenticates with never leaves the custody you already trust. The agent itself never holds these secrets, a model covered across this series: they are presented to the declared destination at the moment of use.
Audit records go to a bucket you own. Every request an agent makes, allowed or denied, is written to storage in your account, on your retention schedule, feeding your SIEM. When an auditor asks what your agents did last quarter, the answer is in a bucket you control, not in a vendor's dashboard you can only read. This is the difference the joint guidance was pointing at: monitoring you operate.
What your developers see
A security architecture that developers hate does not survive, so it is worth saying what the people using it experience.
Developers work in Spaces, each an isolated environment running the coding agent of their choice, with ports and files that behave as if the work were local. The guardrails, credentials the agent never holds, egress under policy, actions judged by verb and target, are part of the environment rather than a stream of prompts in the way. Headless work runs through governed agents triggered by events, with pre-declared grants, as described in the post on human-in-the-loop for headless agents. The experience aims to feel like a fast local machine that happens to be governed, not like a locked-down remote desktop.
Identity integration meets your existing stack rather than replacing it: Google SSO today, with SAML and Okta SSO and SCIM provisioning coming for Enterprise.
Who it is for
Marshal is built for security and platform teams that need agents to run inside their own boundary rather than a vendor's. It is offered in tiers that scale with team size, from a first security control on day one through to multi-cluster and regulated deployments, all self-hosted in a cluster you run.
If "runs in our VPC" is a requirement for your team rather than a preference, this is the shape of deployment built for you.
Self-hosting Marshal means the parts that matter stay yours: the cluster it installs into, the key manager that holds your secrets, and the bucket that holds your audit trail. The security argument does not rest on trusting a vendor's cloud or a vendor's logs, because the enforcement boundary lives inside your own. For teams whose answer to "can this run in our VPC" has to be yes, that is the whole point.
To see what the governed developer experience looks like day to day, start with the false choice between banning agents and letting them run →
Marshal installs into your own Kubernetes cluster with Helm, keeps secrets in your KMS or Vault, and writes every audit record to a bucket you own. Book a demo →