Bound generated code by its trust level

Learning objective

Constrain filesystem, network, secret, and Identity and Access Management (IAM) access according to the trust level of generated code. Assign the smallest runtime capability set that lets the code complete its task. This lesson assumes that you have already chosen an execution environment.

Core idea

Treat every generated program as running inside a capability envelope. The envelope is the intersection of four independent controls:

1. Files the process can read or change.
2. Network endpoints it can reach.
3. Secrets it can obtain.
4. Operations its runtime identity can authorize.

Generated code inherits its process’s access. A sandbox can protect the host kernel while the code still reads mounted data, sends data to an allowed endpoint, or uses an attached identity. Google warns against running code from less-protected sources on compute with a privileged service account because processes can obtain its tokens from the metadata server (service account security).

Isolation is not permission. Apply least privilege inside the boundary.

How it works

Classify trust before granting capabilities

Trust is evidence about a specific code artifact and its inputs, not confidence in the model that produced it. Reviews, tests, provenance checks, and controlled inputs can raise trust. Any code or input change requires reassessment.

Use trust tiers to set a default envelope:

The production tier remains limited to capabilities required by its task.

Control each access plane

Filesystem. Mount only the required paths. Prefer immutable input and disposable writable scratch space. Do not mount a developer home directory, .ssh, .env, container runtime socket, or host path into an untrusted execution. Run as a non-root user and use a read-only root filesystem when the toolchain supports it. Antigravity applies the same pattern locally: approved paths are mounted with their assigned access, denied paths are blocked, and other paths are not mounted (Antigravity terminal sandbox).

Network. Deny ingress and egress, then allow required destinations and ports. Malicious code can use reachable endpoints to exfiltrate data or attack another service. Block cloud metadata, cluster control planes, and private ranges unless needed. For public dependencies, use an approved mirror or egress proxy. Kubernetes recommends default-deny policies and filtering workload access to the cloud metadata API (Kubernetes security checklist).

Secrets. Do not expose a secret merely because the surrounding agent or developer can access it. Prefer a trusted broker that performs one bounded operation without returning the credential. If code must receive a secret, limit its scope and lifetime, and keep it out of prompts, logs, command arguments, and artifacts. Google recommends using the Secret Manager API directly and warns that filesystem and environment-variable delivery can increase leakage risk (Secret Manager best practices).

IAM. Give a workload a dedicated identity only when it must call a cloud API. Grant the narrowest role on the narrowest resource, and prefer short-lived workload credentials over downloaded service account keys. Disable automatic service account token mounting when a Kubernetes Pod does not need it (Kubernetes security checklist). Network reachability and IAM authorization are complementary: blocking the API endpoint limits where code can connect, while IAM limits what an authenticated request can do.

Key distinctions and trade-offs

• Sandbox versus capability envelope: A sandbox contains execution. The envelope controls useful authority that remains inside it. You need both for low-trust code.
• Secret versus IAM permission: A credential proves an identity; an IAM policy grants that identity operations on resources. Hiding a key does not correct an overprivileged role, and a narrow role does not make a leaked key safe. A short lifetime reduces exposure time, not permission scope.
• Read-only versus inaccessible: Read-only access prevents modification but still permits disclosure. Sensitive files should be absent, not read-only.
• Approval versus enforcement: Human approval may raise confidence in one artifact. Runtime controls still enforce the limit if the review misses a flaw or a dependency changes.

Tighter envelopes can break compilers or dynamic package downloads. Use scratch volumes, dependency prefetching, internal mirrors, and narrowly scoped brokers instead of permanent broad access.

Architecture / decision scenario

A financial company lets a coding agent generate a validation program for each pull request. It needs repository files, a Python dependency, and sample transactions. It must produce a report without reaching production data.

The platform runs each program in a fresh GKE Agent Sandbox. It mounts an exact source snapshot read-only and provides temporary directories for packages and reports. It allows egress only to an internal package mirror and a validation proxy; it blocks public internet, all other private services, and metadata. The proxy queries sanitized data under its own identity, so generated code receives neither database credentials nor direct database access. The sandbox Pod has no Google Cloud identity.

Generated code reaches only the package mirror and the validation proxy; every other destination is blocked.

After tests and human review, the normal CI system—not the generated program— copies the report to controlled storage and builds the candidate artifact. This design keeps orchestration authority outside the low-trust boundary. GKE Agent Sandbox itself protects the node, and its managed network posture blocks private ranges and metadata but permits public internet egress by default; production designs must account for that exact behavior (GKE Agent Sandbox production guidance).

Common exam traps

• Assuming that sandboxed code needs no filesystem, egress, secret, or IAM restrictions.
• Treating model confidence or a successful test as proof that generated code is trusted.
• Mounting sensitive files read-only, which prevents changes but not theft.
• Allowing unrestricted internet access for package installation, which also creates an exfiltration path.
• Attaching a broad service account and relying on network policy alone, or granting narrow IAM permissions while leaving metadata and credentials reachable.
• Passing production secrets through .env files or environment variables to unreviewed code.

What to remember

• Build a capability envelope across filesystem, network, secrets, and IAM.
• Base trust on evidence about the exact code and inputs, not on the generating model.
• Default unreviewed code to disposable storage, denied egress, no secrets, and no workload identity.
• Use brokers and short-lived, resource-scoped authority when access is unavoidable.
• Keep sandboxing and least privilege as separate, complementary controls.

Knowledge check

References

• Google Cloud, Best practices for using service accounts securely
• Google Cloud, Secret Manager best practices
• Google Cloud, Isolate AI code execution with GKE Agent Sandbox
• Google Cloud, GKE Sandbox
• Google Antigravity, Terminal sandbox
• Kubernetes, Security checklist