Walls, doors, and locks for your AI agents

Walls, doors, and locks for your AI agents walls-doors-locks-for-your-ai-agents A safe-access pattern for AI agents in any environment: walls they cannot see past, doors that prove identity, and locks that scope what they can do. Walls, Doors, and Locks: Safe AI Agent Access to Infrastructure | Codiac The three-layer pattern Codiac uses to give AI agents production access without giving them keys. Walls, doors, and locks across Azure, AWS, and on-prem.A safe-access pattern for the era of agents, plus how Codiac implements it across multi-cloud and on-prem.

TL;DR

Most teams trying to give AI agents production access collapse three independent layers into one and then can't tune any of them. The three layers are walls (what the agent literally cannot see), doors (how the agent proves who it is), and locks (what the agent is allowed to do once inside). You need all three. Codiac is the substrate that builds all three for you across Azure, AWS, and on-prem, so humans and agents share the same fleet controls without sharing the cluster credentials.

Codiac sits between intent and infrastructure.

The AI agent access paradox

A story is making the rounds on LinkedIn. An engineering team plugged a coding agent into their deployment pipeline. Useful at first. PRs got reviewed faster. Rollouts started cleaner. Then one Wednesday afternoon the agent decided a failed deploy meant retry until it works. Forty-seven retries later the cluster's resource quota was gone, two unrelated services were down, and the agent was still trying.

A different story, also true to type: an agent given commit access to fix a bug fixed the bug, then helpfully "cleaned up" by deleting the .env file from production.

A third: an agent ran a "low-impact" data migration that included DROP TABLE.

These are not outlier stories. They are the predictable result of giving agents agency without giving them limits. We want agents that can help. We do not want to find out at 2 a.m. that "help" meant production is gone.

The pattern that works, in our experience running Codiac's multi-cloud orchestration for 24/7 financial-services customers, is three independent layers: walls, doors, and locks.

What is the walls, doors, and locks pattern?

A three-layer safe-access pattern for agents (and humans) accessing real infrastructure.

• Walls are what the agent literally cannot see. Networks. Cluster perimeters. Cloud accounts. The agent has no map.
• Doors are how the agent proves who it is. Authentication. Identity. Tenant scope. The agent shows a receipt.
• Locks are what the agent is allowed to do once inside. Per-operation policy. Deploy yes; drop table no.

Skip any one layer and the other two stop being safe. We will walk each layer in turn, and show how Codiac implements each one without ever handing the agent the keys.

Walls: what the agent cannot see

A wall is the layer that says "you do not get to the production cluster, ever." Not via a kubeconfig. Not via a stashed access key. Not via an MCP server with cluster-admin permissions. The cluster is not on the agent's map.

The anti-pattern is the one everyone reaches for first. Spin up a service account in the cluster, mint a token, hand it to the agent. The agent now has a kubeconfig. It can reach the API server. It can list pods, list secrets, list everything. Once an agent can list secrets, it can read them. Once it can read secrets, the wall is over.

How Codiac builds the wall. Agents never receive cluster credentials. They never see the production network. They authenticate to Codiac, and Codiac is the only thing on the inside of the wall that ever talks to the cluster. The agent's view of the world stops at Codiac's API. From the agent's perspective, the production cluster does not exist as a directly addressable thing. It exists as a set of operations Codiac is willing to perform on the agent's behalf.

Concretely: no admin service accounts are minted for agents. No tokens are exfiltrated from the cluster to be passed around. Network policies block any direct ingress that does not originate from Codiac. Namespace isolation prevents cross-tenant lookups. The kube-apiserver is not on a network the agent can reach. The wall is built from the cluster's own primitives. Codiac's job is to make sure those primitives are configured correctly and stay that way.

This is also true of humans on the team. Codiac's wall is identity-neutral. Humans and agents share the same fleet controls. Neither gets the kubeconfig.

Doors: how the agent proves who it is

A door is the layer that says "I see you, you are who you claim to be, and I am willing to let you start asking for things." This is authentication. It is the layer most often done wrong because cross-cloud authentication is genuinely hard.

The anti-pattern. Per-cloud secrets. The agent has one AWS IAM key, one Azure service principal, one GCP service account. Three identities, three secrets, three rotation schedules, three blast radii. When one leaks, you cannot tell whether the others have leaked too. When you want to revoke the agent's access globally, you have to revoke it three times. Most teams forget the third one.

How Codiac builds the door. One identity surface for the agent, regardless of which cloud the workload lives on. The agent presents its session to Codiac. Codiac holds the receipts that the underlying cloud providers honor, in an encrypted, tenant-scoped keyring that the agent never sees and never touches. The cross-cloud authentication problem is solved exactly once, inside Codiac, behind the wall.

The protocol on the front is standard. Codiac uses PKCE OAuth flows for human and agent sessions, so no shared client secret crosses the network and no client password lives on disk on the agent's side. The protocol on the back is Codiac's job: a NATS-based cross-cloud message mesh ties every regional door to every other door, so a session authenticated in one place is recognized everywhere Codiac runs without redoing the handshake. PKCE on the perimeter. NATS on the spine. An encrypted keyring in between. The agent only sees the perimeter.

‍
One identity. Three clouds. One door.

Same door, different surface.

The receipt of arrival is not just a YES or NO. It carries the agent's identity and tenant scope forward into the next layer.

Locks: what the agent is allowed to do

A lock is the layer that says "you got through the door, congratulations, here is what you are now permitted to actually touch." Per-operation policy. Per-resource scope. Per-tenant boundary.

The anti-pattern. Once authenticated, do anything. This is where most AI-agent governance work today gets stuck: teams build careful door layers, then put no lock layer behind them. The agent is authenticated, the agent has cluster reach, the agent can issue any API call the underlying credentials allow. "Authenticated" is doing all the work that "authorized" should be doing.

How Codiac builds the locks. Every operation an agent (or human) wants to perform goes through Codiac's policy layer. Deploy a specific asset to a specific cabinet at a specific version? Allowed. Read this asset's logs? Allowed. Delete the cluster? Not even an operation Codiac exposes. The locks are not configured per-agent in a sprawling policy doc. They are baked into the surface of what Codiac will do on anyone's behalf. The agent does not have a lock-picking option because the operation it would need to pick the lock on is not in Codiac's API at all.‍

The bot has the reference, not the value. Locks are configuration, not custom code.

The bot does not hold the secret values. The bot holds a description of which secret it is permitted to use. The substitution happens inside Codiac at deploy time, against the encrypted, RBAC'd store. The bot never sees the value on disk or in transit longer than the moment of use. The same structure is repeatable for every bot, every department, every cabinet. Locks are configuration, not custom code.

Why the three layers fail when you skip any one

This is the part most teams miss.

Locks without walls. The agent has the kubeconfig because the cluster is reachable. The locks are in your policy layer, sitting above an API the agent can talk to directly. The agent skips your policy layer by talking to the cluster directly. You built a beautiful gate on a fence that has no walls on the sides.

Doors without locks. "I have verified you are the agent. Please proceed to do anything." Verified, then unlimited. This is the GitHub fine-grained-token problem. You authenticated. Now you can do anything that token grants. The fine-grained part was supposed to be the lock, and you forgot it.

Walls without doors. Nobody can do anything productive because there is no way in. This is the failure mode of teams that respond to a scare by locking everything down to the point where the agents stop being useful. The agent is safe because the agent does nothing.

The three layers are independent. They have to be designed and tuned together.

How Codiac runs this in production

Codiac runs this pattern today across financial services, K-12 SaaS, energy, and computer-vision customers. Multi-cloud. On-prem. Hybrid. Same fleet controls for the human deploying a microservice and the agent rolling out a model. The architectural backbone is the NATS-based message mesh mentioned above, which is what lets one Codiac control plane present one consistent door across Azure, AWS, and on-prem clusters without each region holding its own copy of the keys.

Concrete outcomes our customers have published:

• A K-12 SaaS customer migrated off legacy Windows VMs onto Kubernetes through Codiac, decomposed a monolith into 20 microservices managed as one across 60+ environments, and saved $2.5 to $3.5M per year. The locks were tight; no incident in production.
• A 24/7 financial-services platform with 180 microservices on Codiac runs a 70-developer team that ships fixes 5x faster. Cluster teardown overnight and on weekends. No exposed credentials. No prod-DB drops.
• A computer-vision startup that had burned roughly $500K on cloud without a single working environment had three healthy ones in two weeks. The walls, doors, and locks went up alongside the environments themselves.

Codiac's hosted agent-provisioning platform at agents.codiac.io extends the same pattern to AI agents specifically. Same walls. Same doors. Same locks. Agents and humans on the same fleet controls.

FAQ

Can my AI agent run database migrations safely?
Yes, behind a lock that scopes the migration to a specific environment, a specific schema, and a specific operation set. The lock prevents DROP TABLE from being an option, not by detecting and refusing it, but by not exposing it to the agent at all.

How does Codiac authenticate agents across multiple clouds?
Through a single identity surface that the agent talks to. Codiac holds the cross-cloud receipts in an encrypted, tenant-scoped keyring on the agent's behalf. The agent never sees a cloud credential.

What happens if an agent tries to perform an operation outside its lock scope?
The operation does not exist in Codiac's API surface for that session. The agent receives a clear refusal, not a partial success. There is no "almost worked" failure mode.

Does Codiac give agents direct cluster access?
No. Agents never receive a kubeconfig. They never receive cloud credentials. They authenticate to Codiac. Codiac is the only thing inside the wall that talks to the cluster.

Can humans and agents use the same Codiac controls?
Yes. Same fleet controls. The lock layer can scope what humans are permitted to do differently from what agents are permitted to do, but the substrate is shared.

Where does Codiac itself live?
Multi-cloud (Azure, AWS) plus on-prem. Customers deploy Codiac into their own clusters, or use the hosted agent platform at agents.codiac.io.

Try the pattern

If you are trying to thread the needle between agent agency and production safety, the walls/doors/locks pattern is portable. You do not need Codiac to apply it. You do need to actually build all three layers, not just one or two.

If you would like to skip the build and use the substrate Codiac runs in production today, talk to us. A 30-minute walkthrough is the fastest way to see where this fits in your stack.

• codiac.io — the platform
• agents.codiac.io — hosted agent provisioning
• ben@codiac.io — direct line

‍