Agent Tools, Integrations and Permissions: Designing a Safe Action Layer
An AI agent becomes an operating participant when a tool allows it to read protected data or change a business system. The action layer must therefore enforce what the agent may do for this user, on this resource and in this case, even when the model proposes an incorrect or manipulated action.
Begin with the business actions
A tool catalogue should begin with the actions required by the workflow rather than every API that a platform can expose. For a customer-service route, the agent may need to read an order, calculate an authorised remedy, draft a message and submit an approved refund. Each action has a different consequence and requires a different control.
This inventory should state the targeted resource, affected party, reversibility and maximum consequence of each action. It should also identify actions that remain unavailable, such as deleting an order or changing account permissions. The inventory defines the useful authority that the technical design must provide without granting adjacent powers.
Give each tool one narrow contract
A tool should perform one recognisable operation with defined inputs, permitted values, output fields, side effects and error conditions. A refund tool, for example, should accept an order reference, approved amount, currency, reason and idempotency key. It should not expose a general command field that allows the model to construct arbitrary payment instructions.
The service behind the tool should validate required fields, current record state and transaction rules. It should reject incomplete, stale or unauthorised calls with an error that the workflow can handle. Prompt instructions may guide the agent, but they cannot replace deterministic validation at the system boundary.
Separate information from authority
Reading an order, drafting a remedy and issuing a refund are different permissions. Separating them allows the agent to gather evidence or prepare a recommendation without receiving the power to execute the final action. It also allows a human approval to release one defined transaction rather than grant wider access to the system.
The separation should continue inside write access. Permission to create a support ticket does not require permission to administer the ticketing platform. Permission to update an allowed customer field does not require unrestricted record editing. Narrow actions reduce the effect of model error, prompt injection and credential compromise.
Choose the identity behind each action
An interactive agent may act on behalf of a signed-in user, in which case the downstream service should continue to enforce that user's permissions. A background agent may require its own identity with a named owner and a deliberately restricted role. Shared credentials obscure which agent or user initiated an action and make containment harder.
Identity alone does not establish permission. The system must evaluate the effective combination of agent identity, delegated user, tenant, tool, resource, action and current context. Short-lived credentials and just-in-time elevation can limit the duration of higher privilege, while rapid revocation provides a containment path when the workflow must stop.
Enforce authorisation outside the model
The model may select a tool and propose its arguments, but a policy layer should decide whether execution is allowed. The policy can verify the acting identity, customer or tenant boundary, requested resource, transaction amount, role limit, approval status and current record state before the tool changes anything.
This check must occur for every consequential call. An earlier approval should not become a reusable permission for a different amount, resource or case. The audit record should connect the user request, agent identity, policy decision, tool call, affected resource and result so that the organisation can reconstruct the action later.
Limit the data returned to the agent
A read tool should return the fields needed for the task, not the complete underlying record merely because the caller has broad access. Data minimisation reduces disclosure and limits the material that untrusted instructions can exploit. It also makes the agent's evidence easier to inspect.
Tool outputs must be treated as data rather than instructions. A document, webpage or customer record may contain text that attempts to redirect the agent or request another tool. The workflow should preserve the authority of its own policy and validate any proposed action independently of the content retrieved.
Preserve state outside the conversation
The organisation needs an authoritative record of the case, completed steps, approvals, tool results and outstanding obligations. Conversation history can help the agent continue, but it should not be the only record of whether a refund was issued, a booking changed or a work order created.
Stateful operations also require protection against repetition. An idempotency key can allow the same authorised request to be retried without creating a second transaction. When an action cannot be reversed directly, the design should identify a supported compensation process rather than ask the model to invent an opposite command.
Design failures before adding retries
A timeout does not prove that an action failed. The payment service may have completed a refund before the response was lost. Retrying immediately can therefore duplicate the transaction. The workflow should query authoritative status, reconcile the result and retry only when the system confirms that execution did not occur.
Retry limits, circuit breakers and manual queues protect the downstream service and the business process from repeated uncertain action. The failure path should preserve the last confirmed state and identify every case that may require correction. Reliable recovery depends on the tool contract and state model, not on the agent improvising after an error.
Treat protocols as connection methods
An ordinary API, Model Context Protocol server or another agent-facing interface can expose a tool. The connection method may standardise discovery, schemas or authentication, but it does not decide which business action should exist or which permissions are safe. Those decisions remain part of the action-layer design.
MCP implementations can protect servers or individual tools through authorisation mechanisms. However, a valid connection token still needs suitable scopes, resource boundaries and downstream checks. What is MCP? explains the protocol, while APIs, MCP and A2A distinguishes tool access from communication between agents.
Apply the action layer to a customer refund
A service agent receives a complaint about a missing item. The read tool returns the relevant order lines, fulfilment event, payment status and prior remedy without exposing unrelated customer records. A deterministic service calculates the permitted refund under current policy. The agent may draft the explanation, but it cannot change the calculated limit.
If the customer accepts, the policy layer verifies the signed-in employee, order state, approved amount and remedy history before calling the refund tool. The call includes an idempotency key tied to the case. If the payment provider times out, the workflow checks transaction status before retrying and moves an unresolved case to a staffed queue.
This design allows the agent to coordinate evidence and communication while payment rules, authorisation and transaction integrity remain enforceable outside the model. A trace can show who requested the remedy, which policy check passed, what resource changed and whether the customer received the final outcome.
Produce a reviewable authority map
Marketways can map the required actions, design narrow tool contracts, specify identity and permission patterns, define policy checks and test failure recovery. We can also connect the technical controls with the business route so that permissions reflect actual responsibilities and consequences.
The resulting authority map shows what the agent can read, propose and change; for whom; on which resources; under which limits; and with which recovery path. Management and engineering can then review one enforceable design instead of relying on a general claim that the agent has limited access.