2938 Members
Join Permit's SlackEnterprise teams should reconsider their approach to MCP, viewing it not just as a "safe integration protocol," but as a key component in cloud operations and API governance. When an agent can alter infrastructure, manage credentials, or control access, the focus shifts from prompt quality to control-plane security design. The best approach involves implementing RBAC at identity boundaries, runtime policy at execution boundaries, throttling at abuse boundaries, audit logs at accountability boundaries, and human approval at irreversible boundaries.
Initially, MCP was used for retrieval and low-risk tasks, but now its value lies in control-plane actions like modifying cloud configurations and managing API workflows. This highlights the difference between control plane and data plane: the former changes system behavior and access, while the latter handles traffic and data under service contracts. Agents accessing the control plane require governance akin to operators with change authority.
Many teams fail by applying a single permission model to actions with different consequences. Explicit risk classes and guardrails are needed before executing cloud operations or API changes. Useful categories include observe, diagnose, propose, change, revoke, and deploy.
| Risk class | Typical agent action | Minimum controls before execution |
|---|---|---|
| Observe | Read metrics, list resources | Authenticated identity, scoped RBAC, immutable audit log |
| Diagnose | Correlate logs, detect anomalies | RBAC + rate limits + query scope constraints |
| Propose | Draft runbook/policy change | Provenance tagging, human review queue |
| Change | Modify config, apply policy | Runtime policy check, dual-authorization for prod, throttling |
| Revoke | Remove access, disable keys/routes | Break-glass guardrails, explicit human approval, rollback path |
| Deploy | Push infra/API policy release | Environment gates, signed intent, approval chain, post-change verification |
A single allow/deny check at request ingress is insufficient, especially for async tasks that continue after disconnection. Enforcement is needed at session establishment, tool-call authorization, async task creation, and state transitions. Human approval should occur at lifecycle checkpoints, not just initial prompts. High-impact actions require a proposed operation, approval request, and execution only after approval, with structured audit evidence for incident response.
Recent announcements underscore the risks and opportunities. The Nutanix MCP Server launch coverage describes assistants like GitHub Copilot, Claude Code, and Cursor triggering infrastructure actions through Prism v4 APIs while inheriting platform governance controls. However, runtime constraints like time-bound approvals are still needed. The MuleSoft Platform MCP Server guide shows conversational control over discover, govern, monitor, and policy workflows for APIs, which again requires runtime policy on top of inherited permissions. The OpenShift AI CVE-2026-18950 threat analysis highlights the importance of policy constraints even with authenticated users, and the CISA SB26-222 bulletin is a reminder that control-plane exposure moves fast.
API gateways manage HTTP/API traffic, while MCP gateways control tool invocation semantics, including identity binding and authorization. They address different concerns: API gateways focus on route exposure, while MCP gateways handle agent action governance. Permit.io offers a trust layer for MCP connections, adding authorization and consent flows without rewriting integrations.
| Control layer | Why it exists | Example implementation concern |
|---|---|---|
| Identity & delegation | Bind agent actions to verified human authority | SSO/OIDC login, delegated session scope |
| RBAC baseline | Enforce least-privilege role boundaries | Role scoping by environment and tool set |
| Runtime policy | Evaluate context beyond static roles | Risk tier, time window, change freeze, incident mode |
| Throttling & quotas | Contain runaway automation | Per-agent call budgets, burst controls |
| Human approval | Gate irreversible actions | Required approval for revoke/deploy in production |
| Audit & forensics | Prove who did what and why | Tamper-evident decision and execution records |
An effective audit schema should answer "who approved this, under which policy, and what changed." It should include event_id, timestamp, tenant, environment, mcp_server, tool_name, requested_action, risk_class, actor_human_id, actor_agent_id, delegation_token_id, rbac_roles, policy_decision, policy_reason, approval_required, approver_id, async_task_id, async_parent_id, target_resource, before_hash, after_hash, result_status, and correlation_id. This schema prevents shadow administrators by making privilege expansion visible and attributable.
RBAC encodes static entitlements, but MCP tool calls are dynamic and context-dependent. Runtime policy adds the missing context so decisions reflect current risk, environment, and intent.
API gateways govern service traffic and protocol-level controls, while MCP gateways manage AI agent tool invocation and delegated authority. Enterprises use both to solve different control problems.
Use risk-tiered approval. Low-risk actions can proceed without manual review, while high-impact changes require explicit approval with clear diffs.
Claude Code can manage APIs safely when it operates inside a governed control-plane architecture with scoped permissions and runtime policy checks. The client is not the safety boundary; the policy, approval, and audit path is. If those controls are weak, any capable agent client can become a privilege amplifier.
An infrastructure MCP server should enforce least privilege, risk-tiered tool classes, and per-call policy evaluation with environment context. It should also implement throttling, async task guardrails, and explicit approvals for irreversible actions like revoke and deploy. Complete, tamper-evident audit logs are required so teams can trace each decision and outcome.
Async tasks extend risk beyond interactive sessions, so policy checks must continue after task creation. Revalidating at task start, state transitions, and privileged sub-steps prevents bypass when delegation expires or risk posture changes.
Audit every action with a normalized event schema that links human sponsor, agent identity, tool call, policy decision, approval status, and resource diff. Include correlation IDs so child async tasks and retries can be tied back to the original approved intent. Without that chain, teams cannot prove accountability or contain shadow-admin behavior during incidents.
It shows that authentication does not guarantee safety. Weak authorization can be exploited, highlighting the need for policy constraints and complete audit logs.
They provide a runtime trust and authorization layer between MCP clients and servers, complementing platform-native permissions with contextual enforcement and centralized visibility. That layer is most valuable when teams need auditable, per-action decisions across multi-step agent workflows.
Co-Founder / CEO at Permit.io
