A ticket tool accepts an operation argument. The same tool can read a ticket, add a private note, close it, or export its attachments. Giving an agent permission to call that tool may therefore authorize more effects than the reviewer had in mind.
Suppose the agent only needs to summarize tickets. How do you let it read without also letting it close a ticket? You have three places to look: the tool interface, the arguments your policy can check, and the backend's own permissions.
Start with the request
Consider this hypothetical request shape:
{ "tool": "ticket-operation", "arguments": { "operation": "close", "ticket_id": "T-1042", "customer": "north" }}This is an illustrative tool contract, not a Dome API request. All operations share one callable entry point, while the arguments select the business effect.
The authorization foundation separates call-level authority from authoritative business state. Applied here, that means a permit for the Model Context Protocol (MCP) action mcp:call does not, by itself, express which ticket operation the organization intends to allow.
List what each operation can change
| Effect | Stable distinction available at the call | Fact that requires another authority | Design recommendation |
|---|---|---|---|
| Read a ticket | Tool or operation name | Ticket belongs to an accessible customer | Narrow read tool plus backend ownership check |
| Add a private note | Operation and note payload | Caller may contribute to this ticket | Separate write permission and backend entitlement check |
| Close a ticket | Operation and ticket ID | Ticket is eligible for closure now | Separate close operation; validate state at commit |
| Export attachments | Operation, requested scope | Export entitlement and approved data boundary | Dedicated export capability with an explicit review |
You don't need a separate tool for every row. But you do need to decide whether “may call this tool” should include all four operations.
A narrow tool is often easier to review because its name and schema communicate its effect. The cost is a larger catalogue and the need to manage related permissions together.
Compare two workable designs
In the first design, replace the multipurpose tool with ticket-read, ticket-note, and ticket-close. The support summarizer receives only read access. A closure workflow receives a separate permit for the close tool.
In the second, retain the existing tool but constrain the operation argument. Dome's Rules simulation documentation shows how supported per-call arguments are exposed as resource.arguments. That can make the operation distinction available to rules without changing the upstream interface.
For the second design, write down exactly which arguments the rule expects. Test missing keys, unexpected values, and the representation the evaluator receives. Do not assume every arbitrary JSON value survives conversion into a policy attribute; the documentation identifies unsupported forms.
Both designs still require the backend to validate the ticket relationship and current state. The agent supplied customer: north; it did not prove that ticket T-1042 belongs to North.
Can the read-only agent still close a ticket?
For the proposed read-only summarizer, keep the agent and target ticket fixed. Change only the operation.
A useful test set includes a permitted read, a refused close, an unknown operation, a missing operation, and a request for another customer's ticket. Identify which control should refuse each case. The backend ownership case has a different expected decision point from the missing operation case.
Also review alternate parameters that can change the effect. A read operation that accepts an arbitrary query language or destination URL may still expose a much broader capability than its name suggests.
These are proposed tests. Passing the policy cases would establish only the distinctions exercised, not certify the entire tool implementation.
Choose the smaller contract the team can maintain
A tool permission is sufficient when the tool's permitted effects already match the agent's authority. Additional argument policy can be unnecessary for a truly narrow read endpoint.
For a multipurpose tool, choose between splitting and constraining based on how reliably the team can express and review the intended effects. Dome's Tool Gateway supplies the per-call control point; the tool contract determines what distinctions are available there.
Pick one multipurpose tool and fill in the worksheet. Then choose: split its operations, constrain the arguments, or keep the current permission because all its effects are appropriate. Record where the backend must still check ownership and state.