{"slug": "your-mcp-server-needs-a-capability-budget-not-just-auth", "title": "Your MCP Server Needs a Capability Budget, Not Just Auth", "summary": "A developer proposes that MCP servers need a 'capability budget' in addition to authentication, defining a short-lived contract that constrains tool actions, targets, resources, quantity, and expiry. The runtime should revalidate the budget at every stage, and a durable ledger is essential to handle interruptions and avoid duplicate calls. The approach aims to improve security and reliability for AI agent tool invocations.", "body_md": "Most MCP security checklists stop at “is this caller authenticated?” That is necessary, but it does not answer the operational question: what is this tool allowed to do during this run?\n\nA useful boundary is a capability budget: a short-lived, explicit contract for each tool invocation. It should constrain the action, target, resource, quantity, and expiry. The model can request a tool, but the runtime decides whether the request fits the contract.\n\nStart with a deliberately boring schema:\n\n```\ntype CapabilityBudget = {\n  runId: string;\n  tool: string;\n  actions: string[];\n  resources: string[];\n  maxCalls: number;\n  maxBytes?: number;\n  expiresAt: string;\n  approval: \"none\" | \"human\";\n  policyVersion: string;\n};\n```\n\nFor example, a code-review run might receive:\n\n```\n{\n  \"runId\": \"run_8f2\",\n  \"tool\": \"github.create_comment\",\n  \"actions\": [\"comment\"],\n  \"resources\": [\"repo:acme/api:pull:481\"],\n  \"maxCalls\": 1,\n  \"expiresAt\": \"2026-08-14T03:00:00Z\",\n  \"approval\": \"human\",\n  \"policyVersion\": \"p17\"\n}\n```\n\nThe important part is what is absent: no repository-wide write permission, no issue creation, and no unbounded retry allowance.\n\nDo not check the budget only when the agent plans the call. The queue, worker, and tool adapter should all treat the budget as untrusted input and revalidate it.\n\nA dispatch decision can be reduced to:\n\nIf steps 4 and 5 cannot be made durable, a worker crash can turn one approved call into several attempts. That is a reliability bug as well as a security bug.\n\nLet the model propose a sequence, but make the runtime spend from the budget one reservation at a time. A plan such as “inspect, patch, test, notify” should not silently inherit write capability from the first step.\n\nA minimal ledger makes this visible:\n\n| reservation | tool | requested | decision | outcome |\n|---|---|---|---|---|\n| r1 | repo.read | 1 call | allowed | confirmed |\n| r2 | repo.write | 1 call | approval required | pending |\n| r3 | slack.send | 1 call | denied | not dispatched |\n\nKeep pending and unknown distinct. Pending means no dispatch has been recorded. Unknown means dispatch may have happened but confirmation was lost. Only the latter requires provider lookup or an idempotency-key reconciliation before retry.\n\nA capability budget is only real if it survives interruptions. Inject at least these cases:\n\nFor every case, record the expected ledger state, whether a provider lookup is required, and whether a human must reapprove. A green test suite that never forces an unknown outcome is testing the happy path, not the boundary.\n\nIf this runtime must stay available for queued work or browser-assisted tasks, hosting is part of the control plane. A managed runtime such as [managed OpenClaw hosting on Ampere](https://ampere.sh/?utm_source=devto&utm_medium=article&utm_campaign=mcp-capability-budget) can be evaluated as one deployment option, but it does not replace capability checks, prompt-injection defenses, credential scoping, or reconciliation logic.\n\nThe questions to verify are practical: where durable run state lives, how workers restart, how credentials are mounted, how logs are retained, and how you rebuild the same policy version on a clean host. Treat the hosting choice as an availability and recovery decision, not as an authorization decision.\n\nBefore calling an MCP integration production-ready, verify:\n\nAuthentication answers “who is asking?” A capability budget adds “what may happen, where, how often, and until when?” That is the boundary worth reviewing.", "url": "https://wpnews.pro/news/your-mcp-server-needs-a-capability-budget-not-just-auth", "canonical_source": "https://dev.to/zira125/your-mcp-server-needs-a-capability-budget-not-just-auth-32p6", "published_at": "2026-08-13 22:02:56+00:00", "updated_at": "2026-08-13 22:17:07.252374+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "developer-tools"], "entities": ["OpenClaw", "Ampere"], "alternates": {"html": "https://wpnews.pro/news/your-mcp-server-needs-a-capability-budget-not-just-auth", "markdown": "https://wpnews.pro/news/your-mcp-server-needs-a-capability-budget-not-just-auth.md", "text": "https://wpnews.pro/news/your-mcp-server-needs-a-capability-budget-not-just-auth.txt", "jsonld": "https://wpnews.pro/news/your-mcp-server-needs-a-capability-budget-not-just-auth.jsonld"}}