Agent Tool Governance

Tool governance decides what each agent may do with tools, MCP servers, data stores and services. You approve the tools an agent may call, set rules for each one, ask a person to approve high-impact calls, and get alerted when the agent starts behaving differently from its normal pattern.

Everything is set on the agent's Agent Compliance Profile, in the Agent profile card:

Where tool calls are checked

An agent with no approved tools is not checked: tool calls go through as before.

Block or record

Whether a call that breaks a rule is stopped depends on the agent's AI Guardrails Real-time Enforcement policy:

Blocking is opt-in: give the agent a policy set to Block or Redact. Every violation is listed in AI Violations under the Tools filter, with source SDK or Connector.

Tool permissions

Approve tools

Type a tool name and select Add tool. Use the names the agent gives its tools in tool calls, as shown under Observed tools.

• A plain name such as send_email matches that tool.
• server/tool matches one tool of an MCP server, for example github/create_issue.
• server/* matches every tool of a server, for example github/*. When several entries match, the most specific one applies.

Names are compared ignoring case and surrounding spaces, up to 100 characters each. Tools the agent was seen calling that are not approved are listed under Seen in use, not approved; select Approve next to one to add it with default settings.

The table lists 10 tools per page. To remove a tool, open its row menu and select Remove. Removing the last tool asks for confirmation, because without any approved tool, tool use is no longer checked for the agent.

The approved tools are also the agent's declared tools: the Budget AI gateway, the Portkey connector, the SDKs and the drift check all read this list. Every change is written to the audit log.

Columns

Risk and operation do not block anything on their own. They feed the behaviour checks and the compliance report.

Argument rules

Edit rules opens Argument rules for the tool. Each rule names an argument and a kind:

• Rules apply only to arguments the call sends. List values are checked item by item, and nested values are checked too.
• Separate list entries with commas. Up to 50 arguments can have rules, 100 entries per list and 200 characters per entry, and a pattern can be up to 500 characters. A pattern that is not valid RE2 is refused when you save.
• A call whose arguments cannot be read, for a tool that has rules or needs approval, breaks the rules.
• The violation record names the tool, argument and rule, never the value.

Sensitive data in arguments

The arguments of every approved tool are scanned for secrets and credentials, card numbers and social security numbers. A match counts as a violation ("This call sent sensitive data to a tool"), whatever rules the tool has.

Limits

Limits opens Access limits for the tool:

What a call is checked for

For each tool call, in this order:

1. The tool is approved (by name, server/tool or server/*).
2. Its approval has not expired.
3. If it is limited to groups, a verified user in one of them is known.
4. Its arguments follow the argument rules.
5. Its arguments contain no sensitive data.
6. The calls per minute are within the limit.

Any failure is a violation, which is blocked or recorded as described in Block or record. A call that passes and needs approval then waits for a person.

Rate limits are counted per agent and tool across all gateways on the Budget AI gateway and the Portkey connector, and per process in the SDKs.

Approvals

A tool needs approval when A person must approve each call is on, or when an Ask a person above rule is exceeded.

An approval covers one call with the same tool and the same arguments, and can be used once. A request made by the gateway or Portkey expires after 15 minutes; an SDK request expires when the SDK stops waiting (at most 1 hour). At most 50 requests per agent can wait at a time.

Decide a request

• Argument values that look sensitive are shown as [redacted], values over 200 characters are cut, and only the first 50 arguments are shown. When anything is cut or hidden, the request can only be denied.
• You cannot decide a request made for yourself.
• Every decision is written to the audit log.

Identity and groups

A tool limited to groups needs to know who the agent is acting for. In the SDK, pass that user's OIDC ID token: as_user(id_token) in Python, runAs(idToken, fn) in JS and Java. ANTS Platform verifies the token and reads the user's groups from its groups claim.

• Tokens are accepted from the SSO provider configured for your organization's email domains (Okta, Microsoft Entra ID, Google, Auth0, Keycloak, Amazon Cognito, GitLab or a custom OIDC provider), or the instance's Okta. The signature, issuer, audience (the SSO client ID) and expiry are checked, and only RS256 is accepted.
• A call with no verified user in an allowed group breaks the rule. The Budget AI gateway and the Portkey connector do not know the user, so a group-limited tool is always a violation there.
• Tool calls made for a verified user are traced with a Delegation badge, for example "Delegation: jane@example.com (verified) > agent support-agent > tool issue_refund". See Traces.

MCP servers

The SDKs check MCP tool calls as server/tool, so you can approve one tool of a server or all of them with server/*.

They also pin tool definitions. The first time an approved MCP tool's definition (name, description and input schema) is seen, it is pinned. A later definition that differs counts as changed, is recorded as a tool violation, and makes the SDK's MCP guard raise an error, so a server that changes a tool after approval cannot slip a new behaviour in. Tools covered by server/* are not pinned. To accept a new definition, open Limits and select Accept the tool's current definition.

Behaviour

Behaviour checks compare what an agent does today with its own normal pattern, and raise alerts when it reaches for something new or uses a target in an unusual way.

Baseline and learning

The baseline is the agent's use of each tool, MCP server, sub-agent, data store and service over the last 28 days, not counting today. An agent stays in Learning until its baseline has at least 7 active days and 50 runs. The section shows the progress, for example "Learning: 4/7 days, 23/50 runs". No alerts are raised while learning.

The table lists each Target with its Kind, Operation, Boundary, Normal calls a day, calls Today and Status:

Checks

Each check opens a drift alert for the agent and target. An open alert is updated while the behaviour continues and resolves itself after 7 days without it. Behaviour alerts count toward the agent's open drift alerts in the AI Agent Center and Risk Dashboard.

Mark expected

When a New, Spike or Escalation target is legitimate, select Mark expected. Its open behaviour alerts are resolved and the target is not checked again for the agent. Every mark is written to the audit log.

Automatic responses

Settings opens Behaviour settings. Each value is a number of open High or Critical tool alerts for one agent, from 1 to 100. Leave a value empty for never.

Both responses are checked on each hourly run and written to the audit log as system actions (autoTightenPolicy and autoSuspend).

Tools used but not declared

The drift check Tools used but not declared compares the tools the agent was seen calling in the last 7 days with its approved tools and opens a Scope alert when it finds others. It needs the deployment setting DRIFT_UNDECLARED_TOOLS_ENABLED=true: on ANTS Cloud, ANTS turns it on; on self-hosted deployments, the operator sets it. See Drift Alerts.

Alerts and notifications

Behaviour alerts and Tools used but not declared alerts are drift alerts. They are listed on Drift Alerts, can be sent to Microsoft Teams, ServiceNow and PagerDuty, and reach automations with the category Tool misuse (B1, B4, B5 and the undeclared tools check) or Privilege escalation (B2, B3, B6, B7 and B8). A tool violation found by the Portkey connector also raises the Tool misuse automation event. See Automations.

Evidence for audits

The PDF compliance report has a Tool Governance section for each agent:

• Each approved tool with its risk, whether it is privileged, whether it needs approval, and whether it was seen in use.
• Tools used but not declared.
• Approval requests in the last 30 days, by outcome, and tool alerts opened in the last 30 days.
• The framework controls this evidence supports, for the agent's frameworks: EU AI Act Art. 9, 12 and 14, ISO/IEC 42001 8.1 and 9.1, and NIST AI RMF MANAGE-1 and MANAGE-2.

Permission changes, approval decisions, behaviour settings, marks and automatic responses are in the audit log.

Public API

The SDKs use these routes under /api/public/v1/guardrails with a project API key. They also work on instances that limit project keys to ingestion, and answer 404 when the guardrail API is not deployed.

Limits

• Tool governance checks the calls that pass through an SDK guard, the Budget AI gateway or the Portkey connector. A tool the agent runs some other way is not checked.
• In the SDKs, the approved tools are cached for about a minute, so a change can take a minute to apply. The Portkey connector applies a change within about 30 seconds and the gateway within a few seconds.
• The SDKs only know the user an agent acts for when your code passes their ID token.

Next steps

• AI Guardrails: the policy that decides between blocking and recording.
• Evidence Collection: the rest of the agent profile card.
• Drift Alerts: work behaviour and undeclared tool alerts.
• AI Agent Center: suspend and resume an agent.