Agent policy

Agent policyAgent policyProject or Resource rules that approve, hold, or reject an agent the first time it asks for a Resource. The default approves everyone. decides what status an agent gets the first time it asks for one of a ProjectProjectThe isolation boundary for an integration. It holds Resources, agents and agent policy, end users, and Proxy clients.'s ResourcesResourceThe downstream system registered in a Project. Its kind (Token exchange or OAuth client) decides the role AIGW plays.: Approved, Pending (held for a person to decide), or Rejected. It lives under Project → Agents → Agent policy and has four pages: How it works, Domain rulesDomain rulesAgent policy rules that approve, hold, or reject agents from a specific domain and its subdomains. Checked before approval rules., Approval rulesApproval rulesThe part of Agent policy that sets Approve, Hold, or Reject for unverified agents and for each kind of agent proof., and KYA issuersKYA issuersThe per-Project (or per-Resource) whitelist of KYA credential issuers AIGW accepts, each with a minimum trust level..

Default behavior

A Project with no rules of its own uses the system default, which approves every agent. Out of the box, a newly registered agent is therefore Approved automatically and does not wait in Pending. Change the Approval rules if you want new agents held for review.

How an agent is decided

The first time an agent asks for a Resource, AIGW evaluates these steps in order. The first step that applies decides the outcome.

Order	Step	What it checks
—	A person's decision always wins	If someone has approved, rejected, or revoked the agent in the Console, none of the steps below change it.
1	Domain rules	Approve, hold, or reject agents from a specific domain and its subdomains. Checked first.
2	Proof rules	If the agent proves who it is, the rule for each proof applies and the most open outcome wins. A KYA credential only counts if the Resource accepts its issuer.
3	Everyone else	An agent with no proof gets the Unverified agents rule.

Which settings apply

• A Resource's own rules replace the Project's rules. A Resource without its own rules follows the Project; a Project without rules uses the system default (approve everyone).
• For domain rules, a Resource's rule beats any Project rule, and the most specific domain wins (mail.example.com over example.com).

When a change takes effect

• Changing approval rules affects agents the first time they ask. Agents that were already decided keep their status.
• A domain rule set to Reject also cuts off matching agents that were approved or held automatically, on their next request. A person's decision still stands.

Approval rules

Approval rules set the Project default and optional per-Resource overrides. Each row offers three outcomes: Reject (✕), Hold (clock — the agent goes to Pending), or Approve (✓). Click Apply changes to save, or Discard to cancel.

Rule	Applies to
Unverified agents	Agents with no proof of who they are.
Platform-trusted	Agents whose domain is on the platform's trusted list.
Web Bot Auth	Agents that signed their request with Web Bot Auth.
Reverse DNS	Agents whose network address resolves back to their own domain.
KYA credential	Agents holding a credential from a KYA issuer the Resource accepts.
Hosted metadata	Agents that serve their own client metadata document (CIMD) from their domain.

An agent holding several proofs gets the most open decision among them. Reset to system default removes the Project's own rules.

The Resources table on the same page shows the status each Resource gives a new agent and whether it Inherits project rules. Use Edit rules on a Resource to give it its own policy — changing any rule there stops that Resource from following the Project. Bulk edit applies changes to several Resources at once.

KYA issuers

KYAKYAKnow Your Agent: a credential from a third-party issuer that vouches for an agent. issuers is the whitelist of Know-Your-Agent credential issuers whose credentials can vouch for an agent. The approval rules use it when evaluating the KYA credential proof.

The selector at the top switches between the Project whitelist and Resource-specific whitelists (Resources either inherit the Project whitelist or have their own). For each issuer you can turn acceptance on and choose a minimum trust level:

Trust level	Meaning
Trusted	Strongest level. Fully verified and bound to the presenting client.
Known	Verified and bound, one step below Trusted. Applied as the minimum when none is set.
Declared	A reference only. Proof arrives later, with a signed request.
Unbound	Verified, but could not be tied to the client presenting it.
Untrusted	Weakest level. No verification is established.

The catalog lists the KYA issuers AIGW supports; some are shown as Disabled and cannot be enabled yet. If no issuer is accepted, agents are decided by the approval rules like any other agent.

Domain rules

Domain rules approve, hold, or reject agents from a specific domain and its subdomains, either for the whole Project or for one Resource. This page currently shows Not built yet.

Related

• Agents — the Pending / Approved / Rejected / Revoked lists and manual decisions.
• Register with AIGW — how agents get registered in the first place.