Governed MCP API for Enterprise Agents — Scopes & Receipts

The failure mode is not “agents” — it is shadow APIs Teams adopting LLM agents rarely fail because the model hallucinates a summary. They fail because someone wires over-scoped API keys, unaudited HTTP wrappers, or ad-hoc scripts that bypass Business Profiles, connector policy, and export controls. Evercore’s agentic interface is a deliberate answer: give agents the same governed HTTP surface humans use, with MCP-shaped discovery, scope enforcement on every proxied call, and receipts that survive longer than a chat transcript. This is not Encore’s IDE MCP server (encore mcp start). That layer exposes service metadata to editors. Product automation uses POST /assistant/mcp—JSON-RPC tools/list and tools/call with the caller’s Bearer API key. MCP bridge: two tools, one allowlist The HTTP bridge exposes: • evercore_list_routes — discover operations from the Postman-derived catalog embedded in knowledge.generated.ts. • evercore_call_endpoint — proxy method, path, query, and JSON body using the caller's Authorization header. GET /assistant/mcp/tools adds registry metadata (risk level, display hints) for Console UIs. Critical property: routes outside the allowlist never execute. Internal helper paths and chat-unsafe surfaces are excluded at generation time. Agents cannot “guess” an admin endpoint if it is not in the catalog. Example host flow (Cursor / custom) The bridge forwards the Bearer key unchanged. Missing scopes fail at the API gateway with the same errors your CI jobs would see—no silent escalation. Scopes are the real control plane API keys carry granular scopes: files:write, profiles:read, compliance:write, connectors:read, trace:read, storage policy scopes, Hedera/IPFS scopes, and more. Agent keys should be robot principals with least privilege: Identity & Trust in Console groups scopes for humans issuing keys; agents inherit whatever you grant—there is no separate “agent bypass.” Receipts: what agents should return to humans Regulated workflows need artifacts that outlive the model thread: • chainId and trace manifests from upload/trace flows • Compliance export pack digests and manifest SHA-256 • Proof receipt endpoints for shares, data rooms, and trace chains • Workflow run ids with steps_log JSON in Postgres When an agent completes a playbook, the operator-facing answer should cite verifiable identifiers, not paraphrases: > “Uploaded evidence.pdf → tx BSNPu8…; chain matter-2026-014; export pack sha256:ab12…; dry-run run wr_91f passed.” That sentence is auditable. “I uploaded the file successfully” is not. Console workflows: replay before promotion /assistant/console/chat combines the MCP bridge, ec_ tools, optional Composio connectors, and workflow runners with Turnstile abuse protection. Workflow libraries support: 1. Dry-run — queue Pub/Sub-backed execution, persist steps_log, no destructive side effects where configured. 2. Live run — same graph with a runner bearer validated per API key. 3. Resume — paused graphs continue on the next user turn. GET /assistant/console/workflows/:id/runs is how operators inspect what the agent actually did—step names, HTTP results, errors—before promoting automation to production. Treat dry-run as your change advisory board for agentic playbooks, the same way you would gate Terraform applies. How this differs from the docs assistant /assistant/docs/chat is stateless RAG over the public API catalog—great for questions, dangerous as an automation spine. Console copilot and MCP hosts are stateful, scoped executors. Documentation search does not call evercore_call_endpoint; copilot does. Keep the layers separate in security reviews so procurement does not conflate “helpful chat” with “autonomous integration.” SmartWeave and protocol extensions Agents may call SmartWeave routes only if they appear in the allowlisted catalog and the key carries required scopes. SmartWeave remains a programmable state extension on Arweave—not a substitute for profiles, retention, or export policy. If your agent “needs SmartWeave,” the review question is still: which scopes, which tenant isolation tags, which receipts prove the contract action? Security guarantees worth putting in your DPIA Adoption checklist 1. Issue a dedicated API key per agent integration with minimal scopes. 2. Point the host at POST /assistant/mcp; verify tools/list returns only expected operations. 3. Dry-run a multi-step workflow; inspect steps_log for surprising calls. 4. Require agents to output receipt fields in your ticket template (tx id, chainId, export digest). 5. Align webhook subscriptions so external systems receive the same events humans would trigger. Platform reference: /platform/agentic-interface. API shapes: OpenAPI + Postman under /docs`. Closing Agentic automation is inevitable in operations teams. The governance question is whether agents inherit your trust layer or route around it. Evercore’s MCP bridge, scopes, receipts, and replayable runs exist so the answer can be inherit—without forcing regulated customers to choose between speed and defensibility.

Topics

• MCP enterprise API
• governed agent automation
• API scope enforcement
• MCP tools allowlist
• proof receipts workflow
• agentic interface API
• LLM agent governance
• audit-ready agent calls