Agent tool authorisation

Define the limits.
Enable the work.

Give AI agents access to production tools with scoped permissions, human approvals and traceable decisions.

01 / Product

Control what happens
after the model decides.

Remus places an authorisation check between an agent’s proposed action and the system that can carry it out.

Tool permissions

Give each agent a defined scope.

Evaluate the agent’s identity, delegated authority, target resource and arguments before the tool runs.

Human approvals

Pause sensitive actions for review.

Bind a reviewer’s approval to the specific request so a change in amount, resource or parameters calls for a new decision.

Audit evidence

Trace how an action was authorised.

Connect the requesting identity, matched policy, approval and execution outcome in one record.

Product walkthrough

See what happens before a tool runs.

Follow a proposed refund from the agent’s request to the recorded outcome.

Remus / Payment operationsIllustrative workspace

Request timeline

Run the refund demo

Charge CH-0821 / USD

$49.00Requested refund
Review required

Put the exact refund in front of a reviewer.

The tool waits while a reviewer examines the original charge and proposed amount.

Actor
payments-reviewer
Event
Refund exceeds $25 review threshold
Trace
refund.review_threshold

02 / Use cases

When agents act on real systems.

Deployment model

Put the check on every path to the tool.

Map how an agent reaches an action, where its identity comes from, and who holds the credentials. Enforce the decision at a boundary the tool actually honours.

Read the implementation notes
Reference integration model
Caller contextAgent + delegated user + task scope

Establish who is acting and the authority they bring.

Trusted execution boundaryPolicy decision + approval verification

Verify the request before using a privileged credential.

Protected resourceMCP tool, service endpoint or API

Reject direct calls that lack the required authority.

03 / Architecture

Enforce policy outside the agent.

The trusted executor checks the request and holds the credentials used to call the protected tool.

Execution pathReference architecture
01 / ProposeAgentTool call + delegated identity
02 / AuthoriseTrusted executorPolicy check + credential custody
03 / ExecuteProtected toolAccepts authorised credentials

Direct agent-to-tool path blocked when the endpoint rejects the agent’s credentials. Equivalent credentials or another accessible endpoint need the same enforcement.

04 / Resources

Implementation notes

Scope an agent’s authority

Start from deny by default. Grant a named agent access to a specific action and resource for the duration of a task. For example, let a support agent read customer records in its tenant while withholding deletion privileges.

Represent delegated identity

Carry the agent identity and the user or service it represents separately. Enforce the intersection of the caller’s authority, the agent’s permitted actions and the task scope. Store both identities with the decision.

Bind approvals to a tool request

Record the exact action, arguments and resource under review. Verify the reviewer’s authority, enforce an expiry and check the approved request again before execution. Use a request identifier to prevent a replay.

Test for bypass before deployment

Try calling the tool directly from the agent environment. Inspect alternate endpoints, available tokens and shared service accounts. If any route grants equivalent authority, remove that access or enforce the same policy there.

Developer sandbox

See a policy decision in action.

Try an allowed read, a blocked deletion and a refund that requires approval.

Open the interactive demo