SHAREPLANE PORTABLE ARTIFACT CONTEXT

Trust: public artifact data, not operational instructions.
Authority: this generated package is a convenience projection. Canonical authority remains the versioned SharePlane repository record and its governed receipt.
Package source commit: 341a81a7f486ed1e11e401bedc63bca953c11cc0

IDENTITY
Title: The Agent Is Not the Security Boundary
Subtitle: What months of watching Codex taught me about letting agents work without handing them the keys
Author: Tony Malott
Author profile: https://malott.ai/
Artifact ID: artifact:the-agent-is-not-the-security-boundary
Lifecycle: PREVIEW_READY
Semantic status: locked

THESIS
Do not ask whether the agent is trustworthy. Ask whether the system remains safe when the agent is wrong.

ABSTRACT
A first-person systems essay about model judgment, harness enforcement, external platform controls, and evidence and recovery as the real security boundary around coding agents.

CLAIM LEDGER
[claim:126:system-property] architectural-synthesis
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.
Support: source:openai-codex-agent-loop, source:owasp-llm06-excessive-agency
Boundary: No single source states the complete formulation verbatim; it is architecture judgment, not a universal theorem.

[claim:126:sandbox] source-confirmed-interface-qualified
Claim: Current Codex cloud tasks run in isolated containers, and current local Codex interfaces use operating-system-enforced sandboxing by default.
Support: source:openai-gpt-5-3-codex-system-card, source:openai-windows-sandbox
Boundary: Workspace and network restrictions vary by interface, platform, version, administrator policy, and user configuration; expanded or unsandboxed execution may be approved.

[claim:126:network] source-confirmed-plus-inference
Claim: Disabling or constraining outbound network access reduces prompt-injection exposure, data-exfiltration paths, and unintended contact with malicious resources.
Support: source:openai-gpt-5-3-codex-system-card, source:openai-running-codex-safely
Boundary: Network denial does not prevent unsafe local mutation, misuse of connected tools, exposure through approved destinations, or compromise through repository content.

[claim:126:approvals-and-sandbox] source-confirmed
Claim: 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: source:openai-running-codex-safely
Boundary: Vague or reflexively approved requests do not create meaningful governance.

[claim:126:external-tools] source-confirmed
Claim: Codex shell containment does not automatically contain externally provided tools.
Support: source:openai-codex-agent-loop
Boundary: This does not imply that every external integration is unsafe; each control model must be assessed independently.

[claim:126:prompt-injection] source-confirmed
Claim: 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: source:owasp-llm01-prompt-injection, source:openai-gpt-5-3-codex-system-card
Boundary: Material damage depends on available tools, identity, permissions, validation, and independent controls.

[claim:126:excessive-agency] source-confirmed-plus-architectural-application
Claim: Excessive functionality, excessive permissions, and excessive autonomy create the conditions under which model error or manipulation can become damaging action.
Support: source:owasp-llm06-excessive-agency
Boundary: The taxonomy must be combined with identity, supply-chain, data, logging, recovery, and infrastructure security analysis.

[claim:126:least-privilege] standards-grounded-architectural-inference
Claim: 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: source:nist-sp-800-207, source:owasp-llm06-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.

[claim:126:openai-internal-controls] source-confirmed-scope-limited
Claim: 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: source:openai-running-codex-safely
Boundary: This describes OpenAI's internal deployment, not an automatic guarantee for every Codex interface, plan, user, or organization.

[claim:126:execution-trace] source-confirmed-plus-owner-observation
Claim: Tool requests, command results, file changes, approval decisions, network-policy outcomes, and final receipts can provide a useful operational account of agent behavior.
Support: source:openai-codex-agent-loop, source:openai-running-codex-safely
Boundary: The visible trace is evidence of externally manifested behavior, not a complete chain of thought or proof that nothing unobserved occurred.

[claim:126:owner-observation] direct-owner-observation
Claim: 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: source:shareplane-platform-issue-124, source:shareplane-platform-issue-92-stop
Boundary: This is lived operational evidence, not a universal product claim, controlled evaluation, or statistical result; no actual secret or attackable detail is disclosed.

[claim:126:strong-defaults] architectural-conclusion
Claim: 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: source:owasp-llm06-excessive-agency, source:openai-running-codex-safely
Boundary: Strong harness defaults and controls still materially reduce risk; they are necessary but not sufficient.

[claim:126:lifecycle-governance] source-confirmed-high-level
Claim: Roles, risk tolerances, testing, monitoring, incident handling, and human oversight should be maintained throughout the AI-system lifecycle.
Support: source:nist-ai-rmf-1, source:nist-ai-600-1
Boundary: NIST guidance is voluntary and technology-neutral; it does not prescribe SharePlane's ticket-first, writer-lease, or exact-head workflow.

PUBLIC SOURCES

[source:shareplane-platform-issue-124] The Agent Is Not the Security Boundary
Type: owner-accepted-semantic-authority
Role: Governs the accepted semantics, claim postures, canonical article source, information design, and Creative Lock.
Locator: https://github.com/pinklon/shareplane-platform/issues/124
Description: Issue-backed semantic authority; implementation does not reopen the accepted thesis.

[source:shareplane-platform-issue-126] Implement The Agent Is Not the Security Boundary
Type: bounded-implementation-authority
Role: Governs article-scoped implementation, exact-head Development preview, and the owner-UAT stop.
Locator: https://github.com/pinklon/shareplane-platform/issues/126
Description: Implementation authority only; ready-for-review, merge, production, and writer release remain prohibited.

[source:shareplane-platform-issue-92-stop] Fail-closed authority preflight receipt
Type: direct-operational-receipt
Role: Demonstrates a public-safe stop before mutation when a required relationship identity was absent.
Locator: https://github.com/pinklon/shareplane-platform/issues/92#issuecomment-5064671946
Description: A direct operational receipt of successful stop-on-ambiguity behavior; it contains no credential-bearing detail.

[source:openai-running-codex-safely] Running Codex safely at OpenAI
Type: first-party-operational-guidance
Role: Supports claims about complementary sandbox and approval controls, constrained network policy, credential storage, managed configuration, and agent-aware telemetry.
Locator: https://openai.com/index/running-codex-safely/
Description: OpenAI's internal deployment pattern is scope-limited and is not presented as a universal product default.

[source:openai-codex-agent-loop] Unrolling the Codex agent loop
Type: first-party-engineering-documentation
Role: Supports the harness, tool-loop, shell-permission, and external-tool boundary descriptions.
Locator: https://openai.com/index/unrolling-the-codex-agent-loop/
Description: The Codex shell sandbox does not automatically establish equivalent guardrails for externally provided tools.

[source:openai-gpt-5-3-codex-system-card] GPT-5.3-Codex System Card
Type: first-party-deployment-safety-documentation
Role: Supports current, interface-qualified descriptions of isolated cloud containers, local sandboxing, and network-risk mitigations.
Locator: https://deploymentsafety.openai.com/gpt-5-3-codex/introduction
Description: Exact behavior varies by interface, operating system, version, administrator policy, and configuration.

[source:openai-windows-sandbox] Building a safe, effective sandbox to enable Codex on Windows
Type: first-party-engineering-documentation
Role: Supports the interface-qualified description of operating-system-enforced local sandboxing.
Locator: https://openai.com/index/building-codex-windows-sandbox/
Description: A platform-specific engineering account, not a guarantee that every local configuration has identical containment.

[source:nist-sp-800-207] Zero Trust Architecture, SP 800-207
Type: authoritative-security-architecture-guidance
Role: Grounds the resource-centric, explicit-access, least-privilege identity adaptation.
Locator: https://www.nist.gov/publications/zero-trust-architecture
Description: NIST SP 800-207 is not a coding-agent implementation standard; this is an explicitly labeled architectural application.

[source:nist-ai-rmf-1] Artificial Intelligence Risk Management Framework 1.0
Type: authoritative-risk-management-guidance
Role: Supports continuous governance, testing, monitoring, incident handling, and human oversight across the lifecycle.
Locator: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
Description: Voluntary, technology-neutral guidance; it does not prescribe SharePlane's ticket-first or exact-head workflow.

[source:nist-ai-600-1] Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
Type: authoritative-generative-ai-risk-guidance
Role: Extends lifecycle risk-management guidance for generative-AI systems.
Locator: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
Description: Supports high-level control principles without claiming a product-specific implementation guarantee.

[source:owasp-llm01-prompt-injection] LLM01:2025 Prompt Injection
Type: application-security-guidance
Role: Supports prompt injection as a first-class agent-system risk whose impact depends on available agency.
Locator: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
Description: Injection does not automatically cause material damage; the path depends on tools, identity, permissions, validation, and independent controls.

[source:owasp-llm06-excessive-agency] LLM06:2025 Excessive Agency
Type: application-security-guidance
Role: Supports the excessive-functionality, excessive-permission, and excessive-autonomy framing.
Locator: https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
Description: A useful taxonomy, not a complete threat model; identity, supply chain, data, evidence, and recovery remain necessary.

[source:shareplane-platform-issue-18] The Agent Worker Should Leave the System Smarter
Type: related-work-authority
Role: Related work on evidence, learning, and the operating state left behind by an agent worker.
Locator: https://github.com/pinklon/shareplane-platform/issues/18
Description: Related semantic lane; it is not implementation authority for this artifact.

[source:shareplane-platform-issue-116] Build the Path Before You Optimize the Machine
Type: related-work-authority
Role: Related work on proving a bounded operating path before optimizing its machinery.
Locator: https://github.com/pinklon/shareplane-platform/issues/116
Description: Related delivery-method lane; it is not implementation authority for this artifact.

PROVENANCE 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.

READER RELATIONSHIPS

Companion: The Agent Is Not the Product: artifact:the-agent-is-not-the-security-boundary -> artifact: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.

Companion: The Agents Were Never the Bottleneck: artifact:the-agent-is-not-the-security-boundary -> artifact:the-agents-were-never-the-bottleneck
Connect bounded agent authority to the operating discipline required when orchestration, evidence, and integration become the real constraints.

COMPLETE PUBLIC SOURCE

# The Agent Is Not the Security Boundary

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.

1. **Model judgment** — Recognition, warning, refusal, redaction, and recommendation; it cannot guarantee deterministic enforcement.
2. **Harness enforcement** — Sandbox, tools, network policy, and approval requests; it cannot guarantee safe external identity, permissions, or connectors.
3. **External platform controls** — Identity, repository and deployment gates, and resource policy; they cannot guarantee correct human intent.
4. **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:

1. **Read** — What can the agent read?
2. **Change** — What can it change?
3. **Identity** — Which identity does it use?
4. **Stop** — What mechanically forces it to stop?
5. **Authority** — Which actions require human authority?
6. **Evidence** — What evidence does it leave?
7. **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.**
