The Agent Is Not the Security Boundary
What months of watching Codex taught me about letting agents work without handing them the keys
Do not ask whether the agent is trustworthy. Ask whether the system remains safe when the agent is wrong.
- 01Model judgmentAdvisory
Warn · refuse · redact
- 02Harness enforcementEnforced
Approve · sandbox · network
- 03External platform controlsIndependent
Identity · repository · deployment
- 04Evidence + recoveryReconstructable
Receipt · revoke · recover
I have been deliberately boring about coding agents.
I picked one capable system, stayed focused, and learned it deeply.
That system has mostly been OpenAI Codex.
I follow what Anthropic is doing. I pay attention to Claude Code. I am not married to OpenAI, and I have no interest in turning a software vendor into a religion. We already have enough of those.
I stayed with Codex because I had not reached a real requirement it could not meet. Chasing every new model would have given me more interfaces, more half-learned workflows, more duplicated context, and less actual understanding.
Keep it simple.
Learn the system in front of you.
Change when the evidence tells you to change.
That singular focus produced an unexpected benefit. I started noticing how the coding harness behaved around security boundaries.
Most people assign an agent a task and go do something else. I understand why. Delegation is the point.
I have done the opposite more often than is probably healthy. I watch the plans. I watch the commands. I watch the diffs, tool calls, approval requests, failures, and stop conditions. I want to understand what the hell the agent is doing before I trust the operating model around it.
I cannot see every internal inference. The visible trace is not the model’s complete reasoning process.
But it is still operational evidence.
And what I have repeatedly seen is more conservative than the popular image of an AI agent running loose across a machine.
During Cloudflare, GitHub, application, and worker configuration, credentials have accidentally crossed into contexts where they should no longer be trusted. Codex has flagged the exposure, treated the credential as compromised, recommended rotation, avoided carrying the value forward, and stopped rather than normalizing the mistake.
I have watched it redact sensitive material.
I have watched it halt when repository authority was ambiguous.
I have watched it refuse to cross a mutation boundary until the ownership conflict was resolved.
Those observations do not prove that Codex catches every secret or always makes the right decision. They do prove something more useful:
A mature coding harness can add meaningful safety controls around a capable model.
That distinction matters because most of the public argument starts with the wrong question.
The wrong question
People ask:
Can I trust the agent?
I think that is the wrong security question.
The better question is:
Does the system remain safe when the agent is wrong?
The agent may misunderstand the task.
It may follow malicious instructions hidden in repository content, a web page, an issue, an email, or a connected tool.
It may request more authority than the task deserves.
It may confidently select the wrong command.
It may do exactly what it was asked to do when the request itself was poorly designed.
We should not build a security model that depends on those things never happening.
We do not secure operating systems by asking processes to behave responsibly. We constrain identities, permissions, memory, files, networks, and privileged operations.
Coding agents deserve the same level of engineering seriousness.
The model is only one layer
I now think about agent safety as four layers.
- Model judgment
Recognition, warning, refusal, redaction, and recommendation; it cannot guarantee deterministic enforcement.
- Harness enforcement
Sandbox, tools, network policy, and approval requests; it cannot guarantee safe external identity, permissions, or connectors.
- External platform controls
Identity, repository and deployment gates, and resource policy; they cannot guarantee correct human intent.
- Evidence and recovery
Receipts, reconstruction, revocation, and rollback; they cannot prevent every failure.
1. Model judgment
The model can recognize that something looks dangerous.
It can warn that a secret has been exposed.
It can refuse to repeat sensitive information.
It can recommend revocation, rotation, validation, or human review.
That behavior is valuable. I have benefited from it directly.
But model judgment is probabilistic. It can miss the secret format. It can misunderstand the context. It can be manipulated by untrusted instructions. It can correctly identify the risk and still propose the wrong response.
A warning is not a security boundary.
2. Harness enforcement
The coding harness decides what the model can actually do.
It defines the tools available to the agent.
It controls which paths can be written.
It determines whether network access exists.
It decides when a command requires approval.
It executes the command, captures the result, and returns that result into the agent loop.
Current OpenAI documentation describes Codex cloud tasks running in isolated containers and local Codex execution using operating-system sandboxing, with network and workspace restrictions controlled by interface and configuration. OpenAI also describes approvals and sandboxing as separate but complementary controls. The sandbox defines the technical boundary. Approval policy governs requested exceptions.
That is real security engineering.
A model may decide not to write outside the workspace.
A sandbox can make the write fail.
Those are not equivalent.
3. External platform controls
The harness is not the whole system.
GitHub still controls repository permissions, protected branches, pull-request rules, and merge authority.
Cloudflare still controls tokens, zones, accounts, workers, environments, and deployments.
CI still controls which checks must pass.
The operating system still controls local identities, files, processes, and key storage.
A strong coding harness cannot repair a Cloudflare token that can administer every account.
It cannot make an unprotected production branch safe.
It cannot convert a shared permanent administrator credential into least privilege through positive thinking.
It can warn us. It can refuse. It can ask for approval.
But reckless IAM remains reckless IAM, no matter how polite the agent is about it.
4. Evidence and recovery
The system must preserve enough evidence to explain what happened and recover when something goes wrong.
That includes:
- the original request;
- the authority granted;
- commands and tool calls;
- approval decisions;
- file changes and diffs;
- tests and validation;
- network-policy decisions;
- deployment receipts;
- explicit stop conditions;
- credential revocation and recovery actions.
OpenAI has described using agent-aware telemetry internally to correlate endpoint alerts with the user request, tool activity, approval decisions, tool results, and network-policy events surrounding Codex execution.
That is the right direction.
An agent log should not merely say that a command ran.
It should help explain why the command was attempted, what authority existed, what changed, and whether the outcome was accepted.
Warning versus denial
A warning is useful. A denial is a boundary.
Behavioral safeguard
- warns;
- recommends;
- redacts;
- refuses;
- asks.
Mechanical control
- blocks;
- scopes;
- denies;
- requires approval;
- protects;
- records;
- revokes.
Where Codex appears genuinely strong
From both my direct use and OpenAI’s current published material, Codex has several things going for it.
It uses sandboxing as a first-class product control rather than relying entirely on model restraint.
Network access is constrained by default in key execution modes and can be narrowed by policy.
Actions that cross configured boundaries can require approval.
OpenAI’s internal deployment pattern includes managed sandbox modes, domain policies, secure operating-system credential storage, workspace-bound authentication, managed configuration, and centralized telemetry.
The harness also exposes enough of the execution loop that I can inspect plans, commands, results, diffs, failures, and stops.
This does not make Codex intrinsically safe.
It makes Codex unusually governable.
That is a more defensible claim.
Where the comfort can become dangerous
Strong defaults create confidence. Confidence can become carelessness with astonishing speed.
There are several places where we can still get hurt.
MCP servers and connected tools
OpenAI’s own agent-loop documentation makes an important distinction: the Codex shell sandbox applies to the Codex-provided shell tool. External MCP tools are responsible for enforcing their own guardrails.
That means a sandboxed shell does not prove that a connected GitHub, email, cloud, database, or deployment tool is equally constrained.
Every connector is another trust boundary.
We need to know:
- what functions it exposes;
- which identity it uses;
- whether it can read, write, delete, or administer;
- whether sensitive actions require confirmation;
- what evidence it produces;
- how its credentials are revoked.
A read-only agent with a connector that can delete production data is not read-only. It is merely wearing a reassuring label.
Prompt injection
Prompt injection remains a practical design problem.
An agent can encounter hostile instructions in source code, documentation, issues, websites, emails, images, dependency metadata, or tool output.
The important question is not whether the model can ever be manipulated. We should assume it can.
The important question is what manipulated behavior can reach.
OWASP describes excessive agency as the combination of excessive functionality, excessive permissions, or excessive autonomy. That is exactly the right frame.
A manipulated agent with no write tools causes less damage than one holding production credentials and a deployment function.
Approval fatigue
Approvals are useful only when the person approving them understands the decision.
“Allow this action?” is barely governance.
A meaningful approval should identify:
- the exact action;
- the exact resource;
- the identity being used;
- the expected consequence;
- the scope and duration;
- whether the action is reversible.
If every routine command interrupts the operator, the operator eventually clicks approve as a reflex. We have managed to train people to dismiss security prompts for decades, so naturally we are now adding faster software to the arrangement.
The answer is not more prompts.
The answer is better policy: low-risk work inside a narrow boundary should flow, while genuinely consequential actions should stop with enough context for judgment.
Broad and permanent credentials
An agent should not inherit every permission the operator has accumulated over twenty years of administrative archaeology.
The acting identity should be scoped to the task, environment, resource, action, and duration.
Read-only when possible.
Development before production.
Temporary before permanent.
Revocable without dismantling the entire system.
That is basic least privilege. Agentic AI did not repeal it.
The operating method I trust
The more capable the agent becomes, the less I want safety to depend on supervising every keystroke.
My answer has been to narrow authority while allowing meaningful execution freedom inside the lane.
The method is becoming simple.
Ticket before execution
Define the purpose, scope, boundaries, acceptance evidence, and prohibited actions before work begins.
The ticket is not administrative decoration. It is the authority envelope.
One bounded writable lane
One issue. One branch. One pull request. One authorized writer for shared outputs.
The agent can explore and repair inside that lane without colliding with unrelated work.
Least-privileged identity
The agent gets only the resources and actions required for the task.
No broad account token because it was convenient six months ago.
Temporary and revocable credentials
Secrets should be short-lived, scoped, stored outside prompts and files, and easy to rotate.
Once a secret enters an unsafe context, it is dead. Revoke it. Rotate it. Do not conduct a philosophical inquiry into whether anyone probably noticed.
Stop on ambiguous authority
If the system cannot determine who owns the lane or whether the mutation is authorized, stopping is a successful outcome.
A clean refusal with evidence is better than an impressive unauthorized change.
Human judgment at consequential gates
I retain decisions involving meaning, risk acceptance, production impact, irreversible actions, and final promotion.
The agent handles the mechanical path needed to produce a reviewable result.
Exact-head validation
I want evidence tied to the exact code and artifact being approved.
Not a test that passed three commits ago.
Not a preview built from a neighboring branch.
Not a production rebuild that might differ from the reviewed artifact.
Receipts for actions and stops
Every consequential mutation should leave evidence.
So should every important refusal.
A blocked agent that explains the authority conflict has contributed useful control evidence. It has not failed merely because it did not produce code.
A successful stop
| Boundary | Exact result |
|---|---|
| Authority evidence | Required authority hashes were recomputed and matched. |
| Missing identity | A required related Work had no admitted Platform identity. |
| Prohibited interpretation | Creating the relationship mapping would have required implementer interpretation. |
| Stop point | Execution stopped before branch creation. |
| Mutation result | No repository mutation, pull request, generated output, or preview was created. |
| Recovery path | The receipt identified the owner-controlled prerequisite needed to continue. |
Recovery before autonomy
Before expanding authority, define how to revoke the identity, roll back the change, isolate the environment, restore the artifact, and reconstruct the decision path.
If recovery is vague, autonomy is premature.
The seven-question agent-safety preflight
Before granting an agent a writable lane, ask:
- Read
What can the agent read?
- Change
What can it change?
- Identity
Which identity does it use?
- Stop
What mechanically forces it to stop?
- Authority
Which actions require human authority?
- Evidence
What evidence does it leave?
- Recovery
How are credentials revoked and damage recovered?
Fear is reasonable. Blind trust is not.
People are right to be cautious about coding agents.
We are allowing software to inspect repositories, execute commands, call APIs, change infrastructure, and prepare deployments. Pretending that concern is irrational would be marketing, not engineering.
But fear should be aimed at the right thing.
The model is not the only risk.
The real danger is a capable agent connected to broad identities, weak boundaries, unrestricted tools, vague approvals, and systems that leave no usable evidence.
The opposite is also true.
A capable agent operating inside a mature harness, least-privileged identities, protected platforms, deterministic authority, and recoverable workflows can be governed with a level of visibility that many manual operations never had.
That does not eliminate risk.
It makes the risk legible, bounded, and manageable.
The conclusion
I am not asking anyone to trust Codex because I have had a good experience with it.
I am saying that the coding harness matters far more than most people realize.
Codex has earned some confidence from me because I have watched it operate, watched it stop, watched it handle boundaries, and compared those observations with the controls OpenAI has publicly documented.
That confidence remains conditional.
I still want scoped credentials.
I still want protected branches.
I still want explicit authority.
I still want exact-head evidence.
I still want revocation and recovery.
I do not want the agent to become the security boundary.
Do not trust the agent more. Build the system so trust matters less.
Check the work, not just the conclusion.
Public research, authority, lineage, and author testimony are labeled separately. Sources can corroborate, challenge, or bound the argument; they do not replace Tony Malott's judgment.
Take the complete artifact with you.
The deterministic package contains a self-contained offline article, the exact public-route snapshot, canonical public metadata, receipt, source text when available, plain-text context, claim ledger, source records, and a member-hash manifest.
Sources, authority, and lineage
Each record states the role it plays. Research support and governance provenance are not treated as interchangeable.
The Agent Is Not the Security Boundary
Governs the accepted semantics, claim postures, canonical article source, information design, and Creative Lock.
Issue-backed semantic authority; implementation does not reopen the accepted thesis.
Open sourceImplement The Agent Is Not the Security Boundary
Governs article-scoped implementation, exact-head Development preview, and the owner-UAT stop.
Implementation authority only; ready-for-review, merge, production, and writer release remain prohibited.
Open sourceFail-closed authority preflight receipt
Demonstrates a public-safe stop before mutation when a required relationship identity was absent.
A direct operational receipt of successful stop-on-ambiguity behavior; it contains no credential-bearing detail.
Open sourceRunning Codex safely at OpenAI
Supports claims about complementary sandbox and approval controls, constrained network policy, credential storage, managed configuration, and agent-aware telemetry.
OpenAI's internal deployment pattern is scope-limited and is not presented as a universal product default.
Open sourceUnrolling the Codex agent loop
Supports the harness, tool-loop, shell-permission, and external-tool boundary descriptions.
The Codex shell sandbox does not automatically establish equivalent guardrails for externally provided tools.
Open sourceGPT-5.3-Codex System Card
Supports current, interface-qualified descriptions of isolated cloud containers, local sandboxing, and network-risk mitigations.
Exact behavior varies by interface, operating system, version, administrator policy, and configuration.
Open sourceBuilding a safe, effective sandbox to enable Codex on Windows
Supports the interface-qualified description of operating-system-enforced local sandboxing.
A platform-specific engineering account, not a guarantee that every local configuration has identical containment.
Open sourceZero Trust Architecture, SP 800-207
Grounds the resource-centric, explicit-access, least-privilege identity adaptation.
NIST SP 800-207 is not a coding-agent implementation standard; this is an explicitly labeled architectural application.
Open sourceArtificial Intelligence Risk Management Framework 1.0
Supports continuous governance, testing, monitoring, incident handling, and human oversight across the lifecycle.
Voluntary, technology-neutral guidance; it does not prescribe SharePlane's ticket-first or exact-head workflow.
Open sourceArtificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
Extends lifecycle risk-management guidance for generative-AI systems.
Supports high-level control principles without claiming a product-specific implementation guarantee.
Open sourceLLM01:2025 Prompt Injection
Supports prompt injection as a first-class agent-system risk whose impact depends on available agency.
Injection does not automatically cause material damage; the path depends on tools, identity, permissions, validation, and independent controls.
Open sourceLLM06:2025 Excessive Agency
Supports the excessive-functionality, excessive-permission, and excessive-autonomy framing.
A useful taxonomy, not a complete threat model; identity, supply chain, data, evidence, and recovery remain necessary.
Open sourceThe Agent Worker Should Leave the System Smarter
Related work on evidence, learning, and the operating state left behind by an agent worker.
Related semantic lane; it is not implementation authority for this artifact.
Open sourceBuild the Path Before You Optimize the Machine
Related work on proving a bounded operating path before optimizing its machinery.
Related delivery-method lane; it is not implementation authority for this artifact.
Open sourceWhat is asserted—and how it is bounded
Research, author analysis, and personal testimony remain distinct. Supporting links and caveats stay attached to each claim.
A coding agent's effective safety depends on the model plus its harness, tools, sandbox, network policy, identity, permissions, connected systems, approval design, independent platform controls, telemetry, and recovery model.
Boundary No single source states the complete formulation verbatim; it is architecture judgment, not a universal theorem.
Current Codex cloud tasks run in isolated containers, and current local Codex interfaces use operating-system-enforced sandboxing by default.
Boundary Workspace and network restrictions vary by interface, platform, version, administrator policy, and user configuration; expanded or unsandboxed execution may be approved.
Disabling or constraining outbound network access reduces prompt-injection exposure, data-exfiltration paths, and unintended contact with malicious resources.
Boundary Network denial does not prevent unsafe local mutation, misuse of connected tools, exposure through approved destinations, or compromise through repository content.
The sandbox defines what the execution environment technically permits; approval policy determines when a reviewer must authorize an action that crosses or expands that boundary.
Boundary Vague or reflexively approved requests do not create meaningful governance.
Codex shell containment does not automatically contain externally provided tools.
Boundary This does not imply that every external integration is unsafe; each control model must be assessed independently.
Direct or indirect prompt injection can redirect model behavior and may lead to unauthorized tool use, information disclosure, command execution, or manipulated decisions when the surrounding system grants sufficient agency.
Boundary Material damage depends on available tools, identity, permissions, validation, and independent controls.
Excessive functionality, excessive permissions, and excessive autonomy create the conditions under which model error or manipulation can become damaging action.
Boundary The taxonomy must be combined with identity, supply-chain, data, logging, recovery, and infrastructure security analysis.
The identity actually used by the agent or connected tool should receive only the resources, actions, duration, and environment required for the authorized task.
Boundary Applying zero-trust resource and least-privilege principles to agent identities is an architectural adaptation, not a NIST coding-agent implementation standard.
OpenAI reports using managed sandbox modes, network policy, keyring-backed credentials, workspace-pinned authentication, managed configuration, and centralized agent-aware telemetry in its internal Codex deployment.
Boundary This describes OpenAI's internal deployment, not an automatic guarantee for every Codex interface, plan, user, or organization.
Tool requests, command results, file changes, approval decisions, network-policy outcomes, and final receipts can provide a useful operational account of agent behavior.
Boundary The visible trace is evidence of externally manifested behavior, not a complete chain of thought or proof that nothing unobserved occurred.
Tony has repeatedly observed Codex flag unsafe credential exposure, recommend rotation, avoid carrying the secret forward, redact sensitive values, and stop at unresolved security or authority boundaries.
Boundary This is lived operational evidence, not a universal product claim, controlled evaluation, or statistical result; no actual secret or attackable detail is disclosed.
A strong coding harness cannot compensate for permanent broad credentials, unprotected production branches, unrestricted connectors, shared administrative identities, weak deployment gates, or absent recovery procedures.
Boundary Strong harness defaults and controls still materially reduce risk; they are necessary but not sufficient.
Roles, risk tolerances, testing, monitoring, incident handling, and human oversight should be maintained throughout the AI-system lifecycle.
Boundary NIST guidance is voluntary and technology-neutral; it does not prescribe SharePlane's ticket-first, writer-lease, or exact-head workflow.
Public boundary. Only owner-accepted public-safe article semantics, current public sources, and sanitized operational receipts are included. No real secret, private machine identity, credential locator, account identifier, or attackable configuration is exposed.
Continue the thinking
Each connection explains why the next work belongs here. The graph records the edge; this layer makes it useful to a reader.