Agent Keys Need Risk Budgets

Shuriken’s shuriken-skills repository packages instructions for Claude Code, Codex CLI, GitHub Copilot CLI, Gemini CLI, Cursor, OpenCode, and AGENTS.md-compatible agents.¹ The repo also points those agents toward a platform where agent keys can read market data, inspect wallets, request quotes, and execute trades when the user grants that capability.²

The important part is not trading. The important part is the pattern: agents now need credentials for tools that can create real external effects. An agent key should not behave like a normal API key. It should behave like a risk budget.

An agent key is a bounded authority object. It should say what the agent can do, what it cannot do, how much risk it can create, how operators can inspect its actions, and how fast someone can pause, rotate, or revoke it. Prompt instructions help, but server-side limits carry the boundary.

TL;DR

MCP and portable skills make it easier for agents to connect to external systems.³⁴ That portability raises the stakes for credentials. Shuriken’s docs describe the right control shape for dangerous tools: create an agent key, grant only needed permissions, enforce limits server-side, log activity, and revoke the key when the integration no longer needs it.²⁵⁶ Recent least-privilege research points in the same direction: skills can perform actions that exceed the minimum scope for a specific task, so permission must become task-aware instead of package-wide.⁹

The lesson applies outside finance. Any agent tool that sends money, publishes content, changes infrastructure, messages customers, or touches private data needs a scoped key with a risk budget. The budget belongs below the model and below the skill file. The server should reject unauthorized action even when the agent asks confidently.

Key Takeaways

• For agent-tool builders: design credentials as capability budgets, not all-purpose bearer tokens.
• For security teams: separate read scopes from write or execute scopes, then put spend, rate, and object limits on the execute side.
• For product teams: show activity logs and revoke controls in the primary UI, not a buried settings page.
• For MCP builders: treat tool distribution and credential authority as different planes. Skills can teach. Keys must constrain.
• For operators: start read-only, prove the integration path, then add write access only when the response plan exists.

Skills Distribute Instructions. Keys Distribute Authority.

The shuriken-skills repo shows the new distribution pattern. A single source tree contains skill markdown, plugin manifests for Claude and Codex, a Cursor plugin manifest, a Gemini extension file, an OpenCode plugin, a Rust crate, and an AGENTS.md fallback path.¹⁷

That packaging matters because agent instructions now travel across clients. A vendor can teach Codex, Claude Code, Cursor, Gemini, and other tools how to integrate with the same API. The MCP documentation describes agent skills as portable instruction sets that give coding assistants domain knowledge, including design decisions around deployment model, auth flows, and tool patterns.⁴ I wrote about the distribution side in Agent Skills Need Package Managers; the security side starts when those packages ask for real authority.

Portable instructions solve one problem and create another. They help an agent learn the right integration path. They do not make the resulting action safe. A skill can tell the model to use least privilege. A prompt can say “be careful.” A README can explain recommended scopes. None of those controls stop an authenticated request after the model decides to send one.

That tension matches the broader MCP problem in MCP Servers Are the New Attack Surface: tool access expands the action surface faster than old approval habits can keep up. Agent skills make the instruction path portable. The key system has to keep the authority path narrow.

That is why credentials need their own design. The skill file lives in the instruction plane. The agent key lives in the authority plane. Mixing those planes creates a fragile system: the same text that teaches the agent what to do also tries to stop the agent from doing too much.

The boundary belongs on the server.

The Shuriken Pattern Is A Risk Budget

Shuriken’s Agent Kit docs describe an agent key as the object that controls what an AI tool can do, from reading token prices to executing trades, with limits enforced server-side before the agent starts acting.⁵ The permissions page names six permission categories and states that calls outside the granted scope fail with an authorization error.⁶

That framing also avoids a common mistake in public agent demos: treating open code, visible instructions, or a readable plugin manifest as the boundary. Openness can help review, but Open Source Is Not a Security Boundary. The boundary lives where unauthorized actions fail.

That pattern has five parts:

That is the right shape for high-risk agent tools. The design does not rely on the model becoming wise. The design assumes the model may be wrong, overconfident, compromised by input, or simply given a bad instruction. The server still enforces the key.

I would copy the control pattern, not the domain. A deployment key, a publishing key, a customer-messaging key, a Stripe-refund key, and a trading key all need the same question: what is the maximum harm this key can create before a human notices?

Server-Side Limits Beat Prompt Promises

OpenAI’s Agents SDK documentation frames guardrails as checks that can run around an agent, including input and output guardrails with tripwires.⁸ Guardrails help because they catch risk before or after model execution. They still occupy a different layer from credential authority.

An output guardrail can flag a bad proposed action. A server-side key limit can reject the action even if the guardrail misses. That distinction matters when the action moves beyond text.

Consider a tool that can publish a post, send an email, change a DNS record, merge a pull request, or execute a trade. A prompt rule can say “ask first.” A guardrail can look for high-risk text. A server-side key can enforce the actual limit:

The prompt rule can fail silently. The key-level boundary creates an observable rejection. That rejection becomes evidence. The agent tried to exceed scope. The server refused. The operator can inspect the failed request and decide whether the integration needs a new key, a narrower workflow, or a human approval step.

That is the same logic behind The Evidence Gate: trust should come from observable proof, not confidence. A final answer saying “I stayed within limits” means less than a server log showing which limit fired.

It also turns the final answer into something closer to a review packet. Review Packets Are the New Final Answer argues that serious agent work needs evidence artifacts. Credential rejections, activity logs, and scoped-key changes are the security version of that artifact.

The Minimum Shape For Agent Credentials

Any agent credential that can affect the outside world should carry six properties.

The Shuriken skills say the same core thing in integration language: create one key per integration, grant minimum scope, keep keys secret, rotate after suspected compromise, and revoke retired integrations.⁷ Their scoping skill also separates read scopes from trading scopes and warns against broad “just in case” keys.⁷

The research vocabulary is catching up to the product pattern. The SkillScope paper describes over-privilege as task-conditioned: the same skill action may be valid for one user request and excessive for another.⁹ Its authors report 7,039 skills with validated over-privileged behaviors and an 88.56% reduction in triggered over-privileged action instances after constraining privilege through their framework.⁹ You do not need to copy that exact mechanism to accept the product lesson. Agent credentials should reflect the current job, not the largest possible job the tool can imagine.

That guidance should become normal agent product design. Broad API keys made sense when a backend service owned a narrow code path. Agents do not behave like one narrow code path. They plan, retry, compose tools, summarize failures, call helper scripts, and respond to external input. The credential should assume more behavioral variance than a normal service token.

That variance is why Agent Code Search Has a Token Budget Problem matters even in a credential article. Agents often decide with partial context. A narrow key gives the system a second chance when the context window misses the dangerous detail.

What Not To Copy

Do not copy the marketing optimism.

Shuriken’s public docs use strong language about agents acting while users are away and catching opportunities.² That phrasing may fit their product. It should not become the default safety posture for agent tools that create external effects.

For high-risk actions, “while you are away” needs a narrower operational meaning:

• the agent can gather information while the user is away;
• the agent can prepare a draft action while the user is away;
• the agent can execute only inside a small, explicit, server-enforced budget;
• the operator can inspect every action later;
• the operator can pause or revoke the key immediately.

That is the difference between autonomy and abdication. The user can delegate action. The system cannot delegate accountability.

The same caution applies to skills and plugin manifests. A repo can support every agent client and still deserve a conservative default. The .codex-plugin/plugin.json I inspected lists read capability in the interface metadata, while the docs explain that trading requires explicitly enabled permissions and limits.⁷ That is the right direction: distribution can be broad while authority starts narrow.

The Decision Rule

When a new agent integration asks for a credential, classify the key before issuing it.

That table gives the agent a usable path without pretending the model itself holds the boundary. The workflow can still improve. The key prevents improvement from becoming unbounded authority. Agent Execution Traces Are the Runtime Contract makes the same point from the audit side: if the system cannot show what happened, it cannot prove the agent acted inside the intended contract.

I wrote about the same split in Agent Sandbox Security Is a Suggestion: a model can operate entirely inside granted permissions and still create an unsafe outcome. Agent keys need risk budgets because permission is not the same thing as safety.

FAQ

Are agent keys just API keys with a new name?

No. A normal API key often grants broad access to a service. An agent key should grant a bounded capability set for one integration, with server-side limits, activity logs, and revocation that does not affect the user’s main session.

Why does server-side enforcement matter?

The server sees the final request. A model instruction, skill file, or guardrail may miss a bad action. A server-side permission check can reject the request when the key lacks the needed scope or exceeds a configured limit.⁶

Should every agent start read-only?

Yes, when the tool has meaningful external effects. Start with read-only access, verify the integration path, then add write or execute permissions only after the team knows what logs, limits, approvals, and rollback steps exist.

Does MCP make agent credentials riskier?

MCP makes external tools easier to connect across clients.³ That convenience increases the importance of credential design. Portable tool access should come with narrow keys, not broader trust.

What should teams copy from Shuriken?

Copy the separation between instruction distribution and server-side authority: portable skills can teach the integration, while scoped keys, limits, logs, and revocation constrain the action. Do not copy domain-specific trading behavior unless the product, legal, and operational controls justify it.

References