Skip to content

Use an EAP agent

This section is for platform consumers — humans and machines that invoke agents running on EAP.

You don't need to know the runtime internals. You do need to know what the platform guarantees, what an execution looks like, and where the boundaries are.

Access EAP

Environment UI and API base URL
Stage https://ccps-eap.stage.webex.com
Production https://ccps-eap.webex.com

Open the environment URL in a browser to use the EAP UI. For external integrations, use the same environment URL as the API base URL and follow the Simple Agent API documentation or ACP extensions documentation for routes, authentication, request formats, and streaming behavior.

Design A Workflow Integration

An application can invoke an EAP Agent as one worker within a larger deterministic workflow. The workflow engine owns pipeline state and station transitions; EAP owns the governed Agent execution at the station that needs working knowledge, adaptive investigation, and tool use.

See Use EAP in a Workflow Pipeline to choose between an end-to-end Agent and a fixed pipeline, select the right worker for each station, and divide responsibilities between the workflow engine and EAP.

Who Can Call An Agent

Access for every project is declared in that project's Registry YAML.

Caller type Identity Authorized via
Human Cisco MyID LDAP authorized_myid_groups in the project YAML
Machine (M2M) Cisco CI OAuth token authorized_client_ids in the project YAML

If your identity isn't in the YAML for that project, the call is rejected at the gateway. There is no implicit "anyone at Cisco" access.

Execution Lifecycle

flowchart TD
    I[User or M2M request] --> G[EAP gateway]
    G --> AUTH{Authorized?
MyID group or
CI client_id}
    AUTH -- No --> REJ[Reject]
    AUTH -- Yes --> S[Sandboxed session]
    S --> GR[Platform guardrails injected]
    GR --> R[EAP runtime executes agent]
    R --> T[Approved MCP tools only]
    T --> E[Evidence]
    E --> D{Action gated?}
    D -- No --> O[Return result]
    D -- Yes --> A[Pause for approval]
    A --> O
    O --> U[Audit + token tracking]

The runtime is always sandboxed and always restricted to the project's approved MCP servers. Network egress outside that list is not possible from inside the agent.

What An Execution Returns

A well-behaved EAP agent gives you:

  • a short explanation of what was checked or attempted
  • the evidence that drove the conclusion (tool outputs, references)
  • the next action, or a clear statement that approval / escalation is required
  • enough trace metadata to review the execution later

If a result isn't justifiable, treat that as a project bug to file against the agent repo — not as a platform limitation to work around.

Platform Guarantees You Can Rely On

Regardless of which project you call, EAP enforces:

  • Non-overridable guardrails — secret protection, tool allowlists, sensitive data handling, refusal of unsafe instructions. These sit ahead of the project's prompt and the agent cannot remove them.
  • MCP-only egress — agents cannot reach the public internet directly.
  • Sandbox isolation — your session is isolated from other customers, projects, agents, and prior sessions.
  • Artifact scoping — only callers authorized for the session can download its artifacts.
  • Audit + kill switch — every meaningful execution is recorded; unsafe or runaway runs can be stopped centrally.

Approval Gates

Write-capable actions (anything that can change system state) are either denied or run behind an approval gate, depending on what the project YAML and runtime policy allow.

If you're a human caller, expect an explicit approval prompt before a gated action runs. If you're an M2M caller, expect either an immediate rejection of the gated step or a deferred-approval flow, depending on how the project integrates with EAP's approval API.

Where To Go Next