Runtime and governance ¶

EAP's runtime exists to enforce platform safety guarantees on every execution, no matter what the customer AGENTS.md says.

Runtime Model ¶

flowchart TD
    U[User or M2M caller] --> GW[EAP gateway]
    GW --> AUTH{Auth
MyID group or
CI client_id}
    AUTH -- denied --> REJ[Reject]
    AUTH -- allowed --> WS[Conversation workspace]
    WS --> SYNC[Load approved repo + ref]
    SYNC --> GR[Apply platform developer instructions]
    GR --> CX[Codex app-server thread]
    CX --> PX[Project-scoped proxy]
    PX --> LLM[Cisco LLM Proxy]
    PX --> MCP[Approved MCP only]
    MCP --> SYS[Target systems]
    CX --> AUD[Audit + token tracking]
    CX -. emergency .-> KILL[Kill switch]

Codex is the primary runtime for EAP projects. Registry entries select it explicitly with agent_runtime: codex.

Non-Overridable Platform Guardrails ¶

EAP supplies gateway-owned developer instructions when it creates or resumes a Codex thread. Project AGENTS.md content cannot remove those instructions. Coverage includes:

• secret and credential protection
• tool access derived from the project's Registry YAML
• sensitive data handling
• protocol-specific artifact and output requirements
• rejection of unsafe or unauthorized instructions

If project instructions conflict with the platform contract, the platform contract wins.

Runtime Configuration Ownership ¶

Project authors own agent behavior, but EAP owns production runtime configuration:

A repository .codex/config.toml can help with local authoring, but it is not an authorization request and must not be treated as permission to expose a provider or MCP server in EAP.

Sandbox Isolation ¶

Code, shell commands, file operations, and tool/MCP calls run inside the platform execution boundary. Isolation applies at these levels:

Controlled Network Access ¶

Production MCP access is generated from the project's Registry YAML. That makes connectivity:

• reviewable — every approved MCP target is in YAML
• governable — adding or removing an MCP is a PR against enterprise-agent-platform-registry
• auditable — configured MCP calls pass through platform-instrumented proxying

Local Codex MCP configuration does not grant production access.

Identity And Access Control ¶

Access for every project is declared in two lists in the Registry YAML:

• authorized_myid_groups — Cisco MyID LDAP groups allowed for human callers
• authorized_client_ids — Cisco Common Identity OAuth client IDs allowed for M2M callers

The gateway enforces both. There is no implicit access. Empty lists mean no callers.

Secrets ¶

All platform and customer credentials live in Keeper Vault and are injected at runtime by Kubed. Neither the project repo nor the Registry YAML contains secret values. Generated Codex configuration references the approved endpoints and environment variable names.

Approval And Mutation Control ¶

Codex sends command, file-change, and permission-profile approval requests to the gateway. EAP translates them into the active caller protocol and returns the decision to the original Codex server request.

flowchart TD
    S[Codex tool request] --> P{Approval required?}
    P -- No --> E[Execute]
    P -- Yes --> C[Gateway asks caller or applies policy]
    C --> D{Approved?}
    D -- Yes --> E
    D -- No --> X[Reject or stop]
    E --> A[Audit record]
    X --> A

AG-UI (deprecated), Simple Agent API, and ACP have different interaction models, so the exact approval exchange differs by protocol. The underlying Codex request remains bound to the same EAP conversation and Codex thread.

Audit, Token Tracking, And Observability ¶

Every meaningful execution retains:

• request context (caller identity, project, conversation)
• model and token usage
• Codex thread and turn context
• tools invoked and their results
• approval decisions
• final summary or artifact references

The runtime also emits health, trace, and metric signals for the gateway, project runtime, and Codex app-server process.

Emergency Kill Switch ¶

When a run misbehaves or a policy violation is detected, the EAP platform team can stop unsafe or unstable execution immediately. A follow-up Git or Registry change is still required to make the correction durable.

Why Service-Level Model Access ¶

Production agent execution cannot depend on a developer's personal model entitlement. Service-level access through Cisco LLM Proxy gives EAP a managed model path, project identity, centralized rate controls, and stable automation behavior.

For the implementation-level architecture behind this runtime model, read EAP architecture.