Why Codex Encrypting Sub-Agent Prompts Matters

OpenAI's Codex just added prompt encryption for sub-agents. It sounds like an infrastructure footnote — it isn't.

What Actually Changed

In a live GitHub issue, OpenAI engineers started encrypting the prompts passed between Codex's orchestrator and its sub-agents. The immediate reason: those prompts were visible in logs and API call traces, which meant anyone with access to those surfaces could read the full instruction set powering the agent.

The fix is prompt-level encryption in transit and at rest for inter-agent communication. Sub-agents now receive opaque payloads they can execute but that observers can't trivially read.

Why Inter-Agent Prompts Are a Specific Risk

Most teams think about LLM security at the boundary — the user-facing input and the model output. That's table stakes. The harder problem in multi-agent systems is the middle layer: what the orchestrator tells sub-agents to do.

Those inner prompts often contain:

• Tool credentials or scoped API keys passed as context
• Business logic that defines what the agent can and can't do
• Intermediate results from prior steps (which can contain customer data)
• System-level instructions that define agent behavior

If those prompts leak, an attacker doesn't need to break your auth. They can read your agent's playbook and, in some architectures, inject into it.

The Prompt Injection Angle

Encryption addresses confidentiality. There's a related problem it doesn't fully solve: prompt injection, where a malicious payload in the environment (a document the agent reads, a webpage it visits) tries to hijack its instructions.

Encrypting prompts between agents helps here indirectly — it makes it harder to inspect and then spoof orchestrator messages. But the real fix for injection is input sanitization and sandboxing at the sub-agent level, which is a separate layer of work. Teams building multi-agent pipelines need both.

What This Means If You're Building Agents Now

If you're using a managed framework like Codex, this is being handled for you — which is the best outcome. If you're building a custom orchestration layer (common in production agent work where you need tighter control), you need to think about this explicitly:

1. Treat inter-agent messages like API calls. Log what you need for debugging, but scope access to those logs carefully.
2. Don't pass raw credentials in prompt context. Use short-lived tokens or a secrets manager; reference them by handle, not value.
3. Audit your trace visibility. LangSmith, Langfuse, and similar tools are invaluable for debugging — make sure they're not inadvertently exposing sensitive prompt content to everyone on the team.
4. Think about trust boundaries between agents. A sub-agent should have the minimum context it needs to complete its task. Orchestrators that dump full session history into every sub-agent call are creating unnecessary exposure.

If you want a quick read on where your current operations are most exposed before you start building, our free AI Opportunity Audit flags the highest-impact automation gaps from your website — useful context before committing to an agent architecture.

The Broader Pattern

This Codex change is a small signal of something larger: multi-agent systems are maturing fast enough that security is becoming a first-class concern, not an afterthought. A year ago most agent demos were single-shot, stateless, and low-stakes. Production agents in 2025 are multi-step, stateful, and touching real systems — payroll, CRM, customer data, internal tooling.

The attack surface has grown proportionally. Builders who treat security as a later problem are going to have a bad time retrofitting it after the agent is already running in production.

The right time to get this right is during architecture, not after the first incident.

If You Want This Built Properly

If you're evaluating whether to build a production agent and want the security architecture done right from the start, book a call — that's exactly the kind of build we take on.