Tools MCP and External Integration
Tool Permission Management — Stack
Tool permission management › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
What matters is whether a decision can consider the arguments, how fast it is, and whether it still says no when its dependencies are unavailable.
- Argument awareness. Whether a rule can read the invocation's parameter values, not only the caller and the tool name. Without this, every consequential distinction has to be encoded into tool names.
- Relationship awareness. Whether the decision can ask about a relationship — does this user own that record, is this repository in that team — or only about roles and attributes held on the subject.
- Evaluation latency. Added time at the high percentiles, on the path of every call, with whatever data fetching the rule requires included rather than assumed cached.
- Fail-closed behaviour. What happens when the policy source is unreachable, and whether the chosen default is configurable per rule rather than globally.
- Decision logging. Whether the result, the rule that produced it, and the inputs it saw are recorded as a unit; an audit that records only denials cannot answer what was allowed.
- Policy authoring and testing. Whether rules can be unit-tested, reviewed as code, and rolled back, or only edited in a console.
- Human-confirmation integration. Whether a decision can return "ask a person" as a first-class outcome with the pending call attached, rather than only allow or deny.
- Revocation latency. How long after a change in entitlements before a decision reflects it, which is the real meaning of removing someone's access.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Policy engines with a dedicated language (Open Policy Agent and Rego, Cedar, Casbin) | Argument-aware rules that are reviewed, tested, and versioned like code | External data must be pushed in or fetched during evaluation; the second puts a network call on every invocation |
| Relationship-based authorisation services (OpenFGA, SpiceDB and similar Zanzibar-derived systems) | Deciding on ownership and containment — this user, that specific record | A graph that must be kept in sync with the systems of record; staleness is the default failure |
| The backing system's own authorisation, enforced by calling as the end user | Avoiding a second place where entitlements are defined | Requires per-user credentials everywhere; the denial arrives after the call has already been made |
| Cloud provider identity and access management for the executing workload | Constraining what infrastructure an agent's runtime can touch at all | Operates on resources and workloads, not on tool invocations with semantic arguments |
| Host-level approval prompts in an interactive client | Developer tooling where a person is watching every action | Approval fatigue, per-user configuration nobody can audit centrally, and no meaning in unattended runs |
| Allow and deny lists in application configuration | Small deployments with a stable, short tool set | Expresses the caller and the tool and nothing about arguments; grows unmaintainable as exceptions accumulate |
| Instructions in the system prompt | Nothing in production | Not a control; it is a preference the model may decline to honour under adversarial input |