Least privilege for AI agents means each agent can call only the tools its work needs. The hard part is that the tools keep changing. Your teams connect new MCP (Model Context Protocol) servers, vendors add tools to theirs, and your developers ship new tools to in-house servers. AI agent permissions written as lists of exact tool names fall behind each time.
The usual workarounds each have a cost:
- A blocklist of risky tools. Easy to start, but a new risky tool isn't on it, so it isn't blocked.
- An allowlist of approved tools. New tools stay blocked, but someone has to update the list each time a team needs one.
SecureAuth Agent Authority takes a third approach to agent authorization: deny by default, then allow by tag. Agents reach their tools through the Agent Authority gateway, which checks every call against your access rules. A rule that allows a tag covers every tool with that tag, including tools on servers you add later.
Start from default deny
In Agent Authority, a tool call that no rule allows is refused. New organizations start with an Allow all rule so agents work on the first day. Once your own allow rules are ready, turn it off. Each agent picks up the change on its next connection, and from then on a new tool stays blocked unless a rule allows it.
Built-in tags say what a tool does
Every catalog tool in Agent Authority carries exactly one of three built-in tags, plus external where it applies:
- Read-only: reads data without changing anything.
- Write: creates or changes data in a way that can be reversed or only adds.
- Destructive: deletes, overwrites, or makes a change that can't be undone.
- External: reaches outside your organization, for example by sending email, posting publicly or fetching any web address.
These are built-in tags that SecureAuth sets on catalog tools, so they mean the same thing in every organization. You can create your own tags alongside them.
Tools on your own MCP servers, and tools a provider adds to a catalog service, are tagged once, when Agent Authority first discovers them, from the hints (annotations) the server publishes about each tool. A tool the server marks as read-only gets the read-only tag, and one marked destructive gets the destructive tag. A tool with no hints gets no built-in tags, and later changes to the hints don't change the tags. The audit log records each assignment, and you can remove or replace tags assigned from hints, or add built-in tags yourself.
Your own tags for agents and services
Your own tags come in two kinds. Resource tags go on services and tools, such as "prod" or "pii". Agent tags go on agents, such as "trusted" or "coding".
Attribute-based authorization: rules that match tags
A rule can match tags, groups and other attributes instead of naming each tool or agent:
- Allow read-only tools for autonomous agents, the agents that act with no person behind each call.
- Allow read-only and write tools for the sales team on Salesforce.
- Allow external tools for agents tagged "trusted".
Before you save a rule, the preview shows where it lands in the list, which rules of the opposite effect it overrides and which rules above it win first. It warns when an allow would win over a deny.
What happens when a new tool arrives
Say you've turned off Allow all, and the only rule that covers your autonomous agents is "allow read-only tools for autonomous agents." Then a service those agents use adds new tools, or you connect a new MCP server. Each new tool is checked by its tags:
AllowRead-only tools for autonomous agents
Allow all is off, so anything no rule allows is blocked.
- list_invoicestagged read-onlyMatches the rule: allowed
- delete_invoicetagged destructiveNo rule matches: blocked
- sync_recordsno tagNo rule matches: blocked
- A tool tagged read-only matches the rule as soon as it's discovered, with no list to update.
- A tool tagged destructive doesn't match, so it stays blocked.
- A tool with no tag doesn't match either, so it stays blocked until someone tags it read-only or writes a rule for it.
Review the tags that come from server hints
A hint is the server's own claim, and Agent Authority can't verify it. If a server marks a tool as read-only and the tool changes data, it still gets the read-only tag, and an allow-read-only rule still allows it. A new tool can also match an active rule before anyone has looked at it, so add only MCP servers you trust.
When you connect an in-house server, review the tags on its tools, especially read-only ones, and tag any tool that has none. Check the tags on new tools too, including tools a provider adds to a catalog service.
How to switch your AI agents to default deny
- Write allow rules by tag for each group and agent type. Start narrow, for example read-only for autonomous agents, and read-only and write for each team's own services.
- Review the tags that came from server hints, and fill any gaps.
- Save each new rule as a draft, check it in the preview, then make it active.
- Turn off the Allow all rule.
Each agent picks up the change on its next connection; a session that's already open keeps the rules it connected with. From then on, a new tool is allowed only when a rule matches its tags. Tag-based rules work as well as the tags they read and the rules ranked above them, which is why the review step matters.
Get started
Default deny, built-in tags and tag-based rules are available to every Agent Authority organization. New to Agent Authority? Start a free 14-day trial.
Full details are in the docs for access policies and tags.
FAQ
How do I give AI agents least privilege access?
Deny every tool by default, then allow only what each agent's work needs. In Agent Authority, you turn off the Allow all rule and write allow rules that match tags, such as read-only tools for autonomous agents. Because the rules match what a tool does rather than its name, they cover new tools without a list to update.
What is AI agent authorization?
AI agent authorization decides whether an agent may make a given tool call. In Agent Authority, the gateway checks each call against your rules, which can match the agent, the user, their groups, the service and the tool's tags. A call that no rule allows is refused.