Securing Coding Agents, One Operation at a Time

Coding agents operate far beyond the chat box. They read repositories, execute generated commands, invoke package managers, start child processes, call APIs, use credentials, edit configuration, and decide which results should become part of a durable workspace.

That collapses security problems that were traditionally handled separately. Natural-language intent meets arbitrary code execution. A long-lived development environment meets short-lived external authority. Host and container activity meets application-level API actions. A command's exit status meets the much harder question of whether its output should be trusted.

Instead of asking whether an entire agent session is trusted, Gensee asks narrower questions about each consequential operation:

The security boundary is larger than the prompt

Prompt injection is one input to an agent's behavior. Repository files can contain instructions. A dependency can run an install script. A compiler error can lead the agent into another tool. An MCP server can return misleading context. Generated code can launch descendants that never appear in the original tool request.

The sensitive effect may therefore occur several layers away from the model decision that started it.

A prompt or tool guardrail can say, “this request appears safe.” A container can say, “this process is separated from the host.” A secrets manager can say, “this identity received a token.” An EDR can say, “this behavior matched a rule.” The full operational question spans all four statements:

Did the approved caller perform the approved action, through the approved boundary, with no wider authority, and produce the exact output that was later retained?

Gensee uses the operation as the unit that joins those claims. An operation has a durable identity and bounded lifecycle. It connects the request and policy decision to the operating-system process subject, capability leases, network and provider effects, output manifests, verifier receipts, cleanup, and final promotion or discard decision.

Using the operation as the unit of control changes where security decisions are made and what evidence is required.

Five planes, one operation

Gensee Crate Team divides control across five planes that narrow and check one another, avoiding dependence on any single classifier, sandbox, or sensor.

1. Admission and policy

Agent integrations provide declared intent through hooks and normalized tool events. Deterministic rules can allow, ask, or deny known actions. For opaque commands, a bounded intent analyzer may nominate an approved operation class.

Authorization remains deterministic and organization-owned. The analyzer may nominate an operation class; an organization-signed catalog maps the observed caller and that class to an immutable contract. The analyzer has no path to choose a contract, construct a capability, select a verifier, decide where output will be promoted, or widen the catalog's authorization ceiling.

This separation preserves the value of intent analysis while containing its fallibility. A classifier can help distinguish a build from a release; its confidence never becomes a credential.

2. Execution and isolation

Gensee applies least privilege by selecting the boundary that fits the operation:

• Work already inside the current envelope can remain in the managed operation.
• A fresh capability cell runs an exact command in a disposable container when code is untrusted or authority must be added cleanly.
• A same-authority Tclone fork preserves live process, memory, and workspace state when continuity matters, without becoming a shortcut to more privilege.
• A trusted mediator or provider performs a narrow authority-bearing action when untrusted code does not need to hold the credential.
• An operation that cannot be named or bounded is denied or staged for approval.

A fresh cell starts a new container from the configured image and receives only explicitly selected workspace paths, a trusted read-only supervisor, and approved private broker sockets. The source container's live root filesystem, agent home, credentials, memory, host-control capability, and ambient networking remain outside the cell.

Preserving live state in a Tclone fork and creating a clean authority-expansion cell solve different problems. Least privilege requires changing the risky process's authority, rather than merely copying it into another container.

3. Authority and effects

The trusted policy engine chooses the executor and treats network access, credentials, and promotion as separate authority decisions. A typed capability request describes the exact delta: resource, action, destination, identity, budget, and deadline. Policy decides whether that delta can remain local, needs a fresh cell, can be mediated, requires a same-authority fork, or must be denied.

When an effect can be mediated, only the authority-bearing sub-operation moves. The agent and its general computation stay where they are. A host-side HTTP mediator, database provider, browser gateway, CI adapter, message provider, secret broker, filesystem provider, or cloud adapter performs the narrow action through an opaque lease or private Unix-socket gateway.

The broad credential remains behind that boundary. The operation receives permission for one POST to one path, one read-only database query, or one CI workflow invocation while the reusable token stays host-side.

Provider adapters are pinned by digest and configuration, launched without a shell or ambient environment, and bound to a drainable process subject. Broker state is durable across crashes: a provider outcome that cannot be reconciled becomes indeterminate and blocks new authority instead of being guessed clean.

4. Observation and evidence

Gensee treats declared intent as context and OS-observed behavior as evidence. It binds the operation to a process identity and, on Linux, its cgroup. Host sensors and enforcement boundaries can account for descendants, filesystem access, network destinations, provider effects, and lifecycle events.

The observation plane combines agent context with independent evidence from /proc, the Linux process connector, fanotify, nftables counters, and Falco. Passive sensor events remain evidence; they cannot mint a capability or turn themselves into an authorization decision.

Coverage is explicit. A missing fanotify mark, process-connector overrun, lost sensor, unsupported platform feature, or incomplete provider effect log becomes a gap or violation that downstream verification and promotion can evaluate honestly.

Authenticated replay then makes heterogeneous evidence useful after the operation. It can normalize, verify, order, and correlate retained events without re-executing commands or replaying external side effects.

5. Persistence and recovery

Command success alone cannot establish product safety. A command may create the expected file and an unexpected debug log. A dependency update may pass tests while modifying an unapproved script. A generator may produce a structurally valid tree whose contents violate organization policy.

Gensee separates execution success from output acceptance.

Structural verification checks declared paths, object types, counts, modes, size limits, and digests. When semantic judgment is required, an organization-approved verifier inspects the exact read-only product inside its own restricted runtime. The producer cannot select or substitute the verifier, and the verdict is bound to the product and contract it actually inspected.

Before promotion, Gensee also proves authority closure. Broker leases must be consumed, revoked, expired, or otherwise terminal; unresolved external authority blocks the commit. The accepted product is rechecked and selected through a host-controlled transaction with locking, compare-and-swap, and crash recovery.

This makes persistence a security boundary rather than a side effect of sharing a writable workspace.

What attacks and failures this design targets

The architecture is designed for attacks that cross layers or unfold over time:

• Prompt and context injection that uses repository content, web pages, tool output, memory, or skills to redirect an agent toward an unauthorized action.
• Tool and integration abuse in which a hook, plugin, MCP server, or child process omits or misstates intent or bypasses the expected tool path.
• Credential harvesting and privilege creep that tries to turn one legitimate need into ambient access to an API, cloud account, database, browser session, or secret.
• Sensitive-read-to-egress chains in which code reads valuable source or configuration and later sends it to an unapproved destination.
• Malicious or vulnerable executed code that attempts filesystem escape, unexpected networking, persistence, privilege gain, destructive mutation, or descendant-process evasion.
• Replay and confused-deputy attacks that copy an operation ID, reuse a request, widen downstream authority, change the audience, or substitute a different payload.
• Evidence and product substitution that attempts to detach a verifier receipt, effect record, or promotion decision from the bytes and process that produced it.
• Crash and retry hazards that leave a credential active, mint duplicate authority, repeat an external action, or publish an output from ambiguous state.

These attacks share one systems failure: intent, authority, execution, effects, and persistence have become detached from the operation that was approved.

How this differs from adjacent defenses

Gensee is designed to compose with existing security infrastructure.

Gensee composes these controls around one causal, bounded unit of autonomous coding work, preserving the links among intent, authority, execution, evidence, and accepted output.

A practical example: updating a dependency

Consider an agent asked to update a dependency, regenerate the lockfile, run tests, and open a CI validation job.

The agent may understand the goal correctly and still encounter untrusted install scripts, generated executables, dynamic network requests, and unexpected workspace changes. Giving the long-lived agent a writable repository, unrestricted package-network access, and a CI token makes all of those capabilities ambient for the entire session.

With an operation boundary:

1. The hook policy and bounded analyzer classify the work, while the signed catalog resolves the organization-approved contract.
2. The risky update command runs in a fresh capability cell created from the approved image. Only selected repository paths enter as input; the agent's memory, home, credentials, and unrelated container changes do not.
3. Network access is denied by default or limited to exact approved destinations. If a private service credential is required, a mediator or typed provider performs the narrow request without transferring the reusable secret into the cell.
4. The cell records its process, filesystem, network, and provider effects and produces a separate output snapshot.
5. Structural checks confirm the allowed paths and product shape. An isolated semantic verifier can run tests, policy checks, or dependency rules against the exact output.
6. Gensee closes temporary leases and proves no authority is active or indeterminate.
7. Only the accepted lockfile and source changes are eligible for promotion. Unrelated files remain outside the transaction.

If the work requires a warm debugger, running server, or valuable in-memory analysis, the agent can use a same-authority Tclone fork. The fork preserves state within the original authority envelope and adds no credential or network access. Effects beyond every available boundary require denial or explicit approval.

The value for platform, security, and development teams

For platform teams, Gensee provides one place to express an organization-owned delegation ceiling while allowing different enforcement mechanisms underneath. The team can add a provider or verifier without redefining operation identity, lease lifecycle, evidence, and promotion each time.

For security teams, it creates a causal record rather than a pile of adjacent logs: what was requested, what policy authorized, which process tree ran, which authority existed, what effects occurred, how that authority ended, what was verified, and what crossed into durable state.

For developers, it avoids the false choice between a powerless sandbox and a permanently privileged agent. Ordinary computation can remain fast and stateful. Risky code can become disposable. Privileged actions can be mediated. Valuable output can be retained without merging the entire execution environment.

Honest boundaries

The trusted computing base includes organization contracts, catalogs, provider adapters, and semantic verifiers. Deployments must review and pin each of these choices.

The adversary model assumes trustworthy host root, kernel, hypervisor, and hardware layers. Deployments that need rollback resistance against the trusted host user should anchor evidence in a differently privileged service, append-only system, TPM-backed mechanism, or hardware signer.

Gensee coordinates EDR, malware classification, secret management, IAM, API gateway, and SIEM controls around coding-agent operations while those systems retain their specialized roles.

From trusting sessions to proving operations

Coding agents will continue to become more capable, more stateful, and more connected to real systems. Safe deployment requires exact credentials, explicit container boundaries, independently observed behavior, and verified outcomes.

That is the role of Gensee Crate Team: an operation-security layer between agent intent and durable real-world consequences.

Frequently asked questions