Step 3

Choose what each agent may do.

Permissions belong to an individual agent. A support agent and a finance agent can use different rules even when they share the same tool.

The three choices

ALLOW

Run immediately after identity and policy checks pass. Use for low-risk actions the agent needs routinely.

REQUIRE_APPROVAL

Pause before execution and ask a human to approve those exact arguments once.

DENY

Block before the function runs. Use for actions this agent should never perform.

Not listed

Denied by default. This protects newly added or forgotten tools.

A practical support-agent policy

permissions = {
    "customer.read": "ALLOW",
    "email.send": "REQUIRE_APPROVAL",
    "customer.delete": "DENY",
}

Read is part of normal support work. Sending an external message has a real-world effect, so a human reviews it. Permanent deletion is outside this agent's job and stays blocked.

Customize by asking three questions

  1. Does the agent need this action to complete its normal task? If no, use DENY or leave it unlisted.
  2. Can this action move money, disclose data, contact a person or make a permanent change? Consider REQUIRE_APPROVAL.
  3. Can you restrict the operation further? Use constraints or move execution to Trusted Gateway for higher-risk work.

Different agents, different authority

# Support agent
{"invoice.read": "ALLOW", "invoice.refund": "DENY"}

# Finance agent
{"invoice.read": "ALLOW", "invoice.refund": "REQUIRE_APPROVAL"}

Use a separate stable agent_id and permissions dictionary for each business role. The dashboard will show each policy separately.

Start narrow

Begin with DENY or REQUIRE_APPROVAL, test the workflow, and grant ALLOW only when the business need is clear. Prompt text is not a permission—Quasentra checks the declared action independently of what the model says.