The Agent Is Not the Security Boundary Tony Malott · Source dated 2026-07-25 https://shareplane.malott.ai/artifacts/the-agent-is-not-the-security-boundary/ SharePlane · Semantic Candidate v03 · Systems essay · The Boundary Test 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. By Tony Malott Updated 2026-07-25 16 min Owner UAT required Agent request What happens when the agent is wrong? 01 Model judgment Warn · refuse · redact Advisory 02 Harness enforcement Approve · sandbox · network Enforced 03 External platform controls Identity · repository · deployment Independent 04 Evidence + recovery Receipt · revoke · recover Reconstructable Boundary test Warning vs denial Stop receipt Preflight Evidence Download Protected Development preview. Semantics and Creative Lock are owner-accepted; presentation remains a candidate pending exact-head owner UAT. Merge and production authority are not granted. 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. The Boundary Test follows an agent request through model judgment, harness enforcement, external platform controls, and evidence and recovery. The Boundary Test follows an agent request through model judgment, harness enforcement, external platform controls, and evidence and recovery. The accompanying structured sequence explains what each stage contributes and cannot guarantee. 01 Model judgment 02 Harness enforcement 03 External platform controls 04 Evidence and recovery 01 Model judgment Recognition, warning, refusal, redaction, and recommendation; it cannot guarantee deterministic enforcement. 02 Harness enforcement Sandbox, tools, network policy, and approval requests; it cannot guarantee safe external identity, permissions, or connectors. 03 External platform controls Identity, repository and deployment gates, and resource policy; they cannot guarantee correct human intent. 04 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 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: 01 Read What can the agent read? 02 Change What can it change? 03 Identity Which identity does it use? 04 Stop What mechanically forces it to stop? 05 Authority Which actions require human authority? 06 Evidence What evidence does it leave? 07 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. Related work Follow the operating argument. #18 · The Agent Worker Should Leave the System Smarter #116 · Build the Path Before You Optimize the Machine Evidence behind the thesis 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. Portable public record 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. Download full artifact package Read plain-text context Inspect package manifest 14 public sources Sources, authority, and lineage Each record states the role it plays. Research support and governance provenance are not treated as interchangeable. Owner Accepted Semantic Authority 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 source Bounded Implementation Authority Implement 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 source Direct Operational Receipt Fail-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 source First Party Operational Guidance Running 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 source First Party Engineering Documentation Unrolling 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 source First Party Deployment Safety Documentation GPT-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 source First Party Engineering Documentation Building 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 source Authoritative Security Architecture Guidance Zero 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 source Authoritative Risk Management Guidance Artificial 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 source Authoritative Generative Ai Risk Guidance Artificial 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 source Application Security Guidance LLM01: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 source Application Security Guidance LLM06: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 source Related Work Authority The 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 source Related Work Authority Build 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 source Claim discipline What is asserted—and how it is bounded Research, author analysis, and personal testimony remain distinct. Supporting links and caveats stay attached to each claim. Architectural Synthesis claim:126:system-property 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. Support Unrolling the Codex agent loop LLM06:2025 Excessive Agency Boundary No single source states the complete formulation verbatim; it is architecture judgment, not a universal theorem. Source Confirmed Interface Qualified claim:126:sandbox Current Codex cloud tasks run in isolated containers, and current local Codex interfaces use operating-system-enforced sandboxing by default. Support GPT-5.3-Codex System Card Building a safe, effective sandbox to enable Codex on Windows Boundary Workspace and network restrictions vary by interface, platform, version, administrator policy, and user configuration; expanded or unsandboxed execution may be approved. Source Confirmed Plus Inference claim:126:network Disabling or constraining outbound network access reduces prompt-injection exposure, data-exfiltration paths, and unintended contact with malicious resources. Support GPT-5.3-Codex System Card Running Codex safely at OpenAI Boundary Network denial does not prevent unsafe local mutation, misuse of connected tools, exposure through approved destinations, or compromise through repository content. Source Confirmed claim:126:approvals-and-sandbox 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. Support Running Codex safely at OpenAI Boundary Vague or reflexively approved requests do not create meaningful governance. Source Confirmed claim:126:external-tools Codex shell containment does not automatically contain externally provided tools. Support Unrolling the Codex agent loop Boundary This does not imply that every external integration is unsafe; each control model must be assessed independently. Source Confirmed claim:126:prompt-injection 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. Support LLM01:2025 Prompt Injection GPT-5.3-Codex System Card Boundary Material damage depends on available tools, identity, permissions, validation, and independent controls. Source Confirmed Plus Architectural Application claim:126:excessive-agency Excessive functionality, excessive permissions, and excessive autonomy create the conditions under which model error or manipulation can become damaging action. Support LLM06:2025 Excessive Agency Boundary The taxonomy must be combined with identity, supply-chain, data, logging, recovery, and infrastructure security analysis. Standards Grounded Architectural Inference claim:126:least-privilege The identity actually used by the agent or connected tool should receive only the resources, actions, duration, and environment required for the authorized task. Support Zero Trust Architecture, SP 800-207 LLM06:2025 Excessive Agency Boundary Applying zero-trust resource and least-privilege principles to agent identities is an architectural adaptation, not a NIST coding-agent implementation standard. Source Confirmed Scope Limited claim:126:openai-internal-controls 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. Support Running Codex safely at OpenAI Boundary This describes OpenAI's internal deployment, not an automatic guarantee for every Codex interface, plan, user, or organization. Source Confirmed Plus Owner Observation claim:126:execution-trace Tool requests, command results, file changes, approval decisions, network-policy outcomes, and final receipts can provide a useful operational account of agent behavior. Support Unrolling the Codex agent loop Running Codex safely at OpenAI Boundary The visible trace is evidence of externally manifested behavior, not a complete chain of thought or proof that nothing unobserved occurred. Direct Owner Observation claim:126:owner-observation 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. Support The Agent Is Not the Security Boundary Fail-closed authority preflight receipt Boundary This is lived operational evidence, not a universal product claim, controlled evaluation, or statistical result; no actual secret or attackable detail is disclosed. Architectural Conclusion claim:126:strong-defaults 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. Support LLM06:2025 Excessive Agency Running Codex safely at OpenAI Boundary Strong harness defaults and controls still materially reduce risk; they are necessary but not sufficient. Source Confirmed High Level claim:126:lifecycle-governance Roles, risk tolerances, testing, monitoring, incident handling, and human oversight should be maintained throughout the AI-system lifecycle. Support Artificial Intelligence Risk Management Framework 1.0 Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile 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. 14 sources 13 governed claims 1 portable package Connected work 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. Foundations Companion: The Agent Is Not the Product The Agent Is Not the Product. The Control Plane Is. Continue from the security boundary into the control-plane architecture that governs work around the agent. The more useful an agent becomes, the less its safety can depend on the agent behaving well. The durable product is the governed execution environment around it. Reader Choice Publication Family By Tony Malott 2026-07-23 complete standalone reading experience · Personal systems narrative, Architecture argument, Enterprise warning Counterpoints and tensions Companion: The Agents Were Never the Bottleneck The Agents Were Never the Bottleneck Connect bounded agent authority to the operating discipline required when orchestration, evidence, and integration become the real constraints. Capable agents became useful when Tony engineered the repositories, access, tools, authority, validation, evidence, and completion paths that made bounded work operational. Systems Essay By Tony Malott 2026-07-20 8 min · Concise long-form argument Explore the complete graph About the author Tony Malott AI architect, systems engineer, and author publishing serious work on agentic systems, architecture, governance, automation, and the operating models around them. About Tony Résumé Email Tony SOURCE REFERENCES The Agent Is Not the Security Boundary https://github.com/pinklon/shareplane-platform/issues/124 Implement The Agent Is Not the Security Boundary https://github.com/pinklon/shareplane-platform/issues/126 Fail-closed authority preflight receipt https://github.com/pinklon/shareplane-platform/issues/92#issuecomment-5064671946 Running Codex safely at OpenAI https://openai.com/index/running-codex-safely/ Unrolling the Codex agent loop https://openai.com/index/unrolling-the-codex-agent-loop/ GPT-5.3-Codex System Card https://deploymentsafety.openai.com/gpt-5-3-codex/introduction Building a safe, effective sandbox to enable Codex on Windows https://openai.com/index/building-codex-windows-sandbox/ Zero Trust Architecture, SP 800-207 https://www.nist.gov/publications/zero-trust-architecture Artificial Intelligence Risk Management Framework 1.0 https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10 Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence LLM01:2025 Prompt Injection https://genai.owasp.org/llmrisk/llm01-prompt-injection/ LLM06:2025 Excessive Agency https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ The Agent Worker Should Leave the System Smarter https://github.com/pinklon/shareplane-platform/issues/18 Build the Path Before You Optimize the Machine https://github.com/pinklon/shareplane-platform/issues/116