Agent Tool Permissions: A Scope Matrix Your Team Can Enforce

Before you can scope anything, you need a list of who is acting. Start with the business function, not the technology. A useful first pass looks like this:

• Support triage agent: reads tickets, drafts replies, never sends.
• Sales research agent: reads CRM records and public web pages, writes notes, never changes deal stages.
• Claims or case review agent: reads case files, drafts determinations, never approves.
• Coding agent: reads a repository, opens pull requests, never merges to production.
• Finance reconciliation agent: reads ledger and bank data, proposes matches, never posts a journal entry.
• Marketing content agent: reads brand assets, drafts copy, never publishes to a public site.

Two rules make this inventory usable. First, one row per role, where a role is defined by the job it does rather than by the model or vendor behind it. If two different assistants both draft support replies, they are one role with one set of permissions. Second, name the human or process each role acts for, because attribution is the first thing an auditor asks about PlainID's permission control framework. An agent running under a single service account called something like svc-claims-ai shows forty thousand database queries and no way to tell which adjuster was behind any of them PlainID.

The policy layer should already have told you which of these roles is allowed to exist. A workplace AI policy needs to state what employees may and may not use AI for, whether they need permission, and which tools are banned, and it should name the responsible officer for violations the Brightmine AI policy guide. Treat that policy as the authority the matrix implements. Where the two disagree, the policy wins and the matrix gets fixed.

Questionnaire answers are useful only if they resolve to named permissions. "Least privilege" and "read-only access" are not scopes. Go back through each vendor response and pull out the specific strings and credential types, and push back where an answer stays abstract.

A practical extraction checklist, modeled on the permissions and logging sections of a structured vendor questionnaire the Wavect EU AI vendor security questionnaire:

Three questions in that list do most of the work. Ask which data the product sends to a model and whether it is the vendor's model or a third party's, ask how long prompts, outputs and embeddings are retained and whether you can set retention to zero, and ask whether you can exclude specific data classes such as personal data, health data or source code from AI processing the Reco AI questionnaire. An answer of "we can't specify" or a third party they will not name is a stop, not a maybe the Reco AI questionnaire.

For health-adjacent data, the bar is higher and the answers must be contractual. What data the vendor touches, how long they keep it, whether they train on it, which controls protect it, who their subprocessors are, and who acts if something goes wrong should all appear in writing, alongside a current SOC 2 Type II report and breach terms with deadlines Censinet's six questions. Their rule is worth quoting into your own process: paper beats promises, and if the vendor will not put these points into the contract, do not proceed Censinet. Be aware that a cloud provider can be a business associate even when it cannot view encrypted health data, so the fourth-party chain counts too Censinet.

Least privilege means granting the minimum permission needed for the function and nothing more Auth0 on OAuth and least privilege. In OAuth terms, scopes are the mechanism that expresses that boundary, and they are defined by the resource server rather than by the standard, so your narrowing work happens per API Auth0.

Start by refusing the request that asks for nothing specific. Requesting an access token without a scope parameter is a security anti-pattern and a direct violation of least privilege, because authorization servers handle that case inconsistently Auth0. For agent workflows, the narrowest useful scope reduces what a stolen token or a misused integration can reach, which is the whole point when a single integration can control many resources at once the NHI Mgmt Group glossary.

Scope inflation is the most common failure, and it happens for a boring reason: it is easier to build once against a broad permission than to design carefully NHI Mgmt Group. A workflow that works with a broad token hides the fact that the same job could have been done with a smaller, safer permission set NHI Mgmt Group. Review scopes as part of design, not as cleanup before launch.

A worked narrowing example for a support triage agent, which is typical of what teams find:

Notice that three of the six changes cost the agent nothing in capability. The draft still drafts. Only the actions that could cause irreversible harm were removed.

Map the result onto the other side of your estate as well. If your internal controls already mandate multi-factor authentication and least privilege for staff, your vendor requirements should require equivalent controls for vendor access into your environment CyberProof on third-party risk. Aligning first-party and third-party expectations stops a vendor-only loophole from opening up CyberProof.

The decision rule that makes a matrix usable is simple enough to apply in a meeting: if the action is irreversible outside your systems, or moves money, or reaches a person you do not control, it needs a named human approver. Reads and drafts can run unattended. Sends, posts, merges, deletes, payments and contract commitments cannot.

Practitioners who work on agent security put the same boundary in operational terms. Tool permissions decide what the agent can read, write, send, spend, deploy, delete or execute, so start read-only and add write access slowly the Kingy agent security guide. Coding agents should run in branches, disposable workspaces or sandboxes, and never get a daily machine, production secrets and auto-merge on day one Kingy. Financial, payment, payroll, tax and banking tools need hard limits: test mode, spending caps, approvals, audit logs and separate accounts Kingy. If you cannot explain what the agent can read, write, spend or send, do not connect it yet Kingy.

Your own AI policy is the place this rule gets teeth. An employee AI policy should explicitly prohibit using AI to make legal or financial decisions, commit the company contractually, or replace professional judgment, while allowing drafting and summarization under conditions the CRI employee AI policy guidance. The same prohibitions apply to an agent acting on an employee's behalf. An agent cannot do what the policy forbids the person to do.

Approval gates also need a shape. Each gated action should record four things before it proceeds: the agent role, the human who approved, the exact action and target, and the policy version that allowed it. That is what turns an audit question into a lookup instead of a two-week reconstruction across prompt logs, tool logs and database logs that share no identifier PlainID. Logging a model like an agent over-collects, but logging an agent like a model misses the action and the chain of reasoning that produced it Collibra on AI audit trails.

A matrix in a spreadsheet is a plan. Enforcement needs two mechanisms: one identity per role, and a check before every tool call.

Per-role service identities. Give each role its own credential, scoped to exactly what the row allows. Never let two roles share a token, and never let a role borrow a human's personal token. The pattern that gets teams in trouble is the borrowed service-account model: one credential granted a role broad enough to avoid errors during testing, left attached long after the pilot ends PlainID. Where a role acts for a specific employee, record that delegation so the log keeps the human in the chain PlainID.

A pre-call policy check. Before the agent invokes any tool, a small authorization service looks up the (role, tool, action, target) tuple in the matrix and returns allow, deny or require approval. This inverts the usual model: instead of granting access and trusting logs to explain it later, you make a decision at the moment of action and record it PlainID. A minimal check, expressed as configuration rather than a specific vendor's product, looks like this:

role: support_triage
tool: email
actions:
  read_messages: allow
  send_message:
    decision: require_approval
    approver: support_lead
    ttl_minutes: 30
  delete_message: deny
retention: 30d
logging:
  record: [role, delegated_user, action, target, policy_version, decision]

A few properties of that block matter more than its syntax. The gate carries an approver role rather than a name, so it survives staff changes. The approval expires, so a stale yes cannot be replayed tomorrow. The decision and the policy version are logged together, which is what an examiner looks for PlainID.

Sandboxing the blast radius. Permissions limit what an agent may do; isolation limits what happens when it does the wrong thing anyway. Agents make mistakes and can be manipulated by hostile content, and browser agents are especially exposed because a malicious page can carry hidden instructions Kingy. Treat isolation as the second layer, not a substitute for scoping.

Review on a cadence, not on demand. Standing privilege accumulates because roles granted for a pilot stay attached after it ends, and agents make that worse because their behavior shifts with each prompt PlainID. A quarterly certification designed for human employees cannot keep pace with agents a platform team can create in an afternoon PlainID. Review each matrix row when the tool changes, when the vendor changes a model, or on a fixed interval, whichever comes first. Model changes and their notification terms belong in the vendor questionnaire for exactly this reason Wavect.

Re-classify existing vendors. A tool approved as a project tracker can ship AI features later, and re-classification is one of the most commonly skipped steps in AI risk programs Reco AI. Put the re-check on the renewal calendar, since that is when you have leverage.

The last row is the one teams miss. If the handbook bars employees from uploading confidential material to public tools and bars AI from committing the company contractually CRI, then an agent holding a personal API key to an external model is a policy breach with a technical implementation. Handbooks are being updated for exactly this reason, and access and use controls belong in them Morgan Lewis on AI and employee handbooks.

The matrix is small enough to maintain and specific enough to enforce. Most organizations find between five and fifteen roles that matter, and a page or two of cells covers them. The work is in the extraction: getting named scopes out of vendors, writing down the deny column, and wiring the pre-call check into your agent runtime.

Two practical starting moves. Pick your highest-blast-radius role, the one touching money or customer records, and build its row first, including one approval gate you can demonstrate end to end. Then schedule a review of every existing AI vendor against the permissions questions in a structured questionnaire Wavect, because the answers you collected at signature have likely drifted since.

If your agents route through several model providers and you want the identity and scoping work to sit behind one interface rather than one per provider, Quanta Inference puts text, image, video, audio and embedding models behind a single OpenAI-compatible API key, which keeps the credential surface you have to scope and audit smaller.