Governance API

The governance API lets your own systems, such as a GRC tool, a CMDB or a compliance pipeline, read the governance, inventory and policy records that ANTS Platform keeps:

• Agents and their governance profiles
• Framework coverage per compliance framework for a project
• Guardrail policies, one per agent
• The AI tool registry used by Discover AI
• Sanctions: the sanction status of each AI tool
• Model approvals from the AI Inventory

It can also change three kinds of record: an agent's governance profile, an agent's guardrail policy, and a tool's sanction status. Writes use the same validation and side effects as the app.

Every read and every write is recorded in the audit log.

Base path

All governance endpoints live under:

Use the same host as the rest of the public API. Paths on this page are relative to /api/public/v1/governance.

Turn it on

Three conditions must all hold before the API returns data. If any one is missing, every governance endpoint answers 404.

Organization API keys also need the organization API keys and Admin API entitlement (admin-api, Enterprise plans). Project keys do not.

Who can change these settings

A custom role grants the first through Organization features & MFA at the Admin level.

Turning the API off, switching back to Read only, and turning Governance write off for a key do not ask for step-up. Turning the API off also resets the access to Read only, so turning it back on never restores write access by itself. Governance write is off for every key until an admin turns it on, including keys created before the API was available.

Every change to these settings is written to the audit log.

Authentication

Use HTTP Basic auth with an API key pair, the same as the rest of the public API: the public key (pk-ap-...) as the username and the secret key (sk-ap-...) as the password. See Authentication.

Which key to use

Every write needs an organization key. Project keys live in application code next to the agents they belong to, so a leaked project key cannot loosen its own agent's guardrail policy, change its risk tier or sanction a tool for the whole organization.

Other credentials, such as Discover AI enrollment keys, are refused with 403. On a deployment where project keys are limited to trace ingestion, project keys are refused with 403 here too; organization keys still work.

Pagination

Every list endpoint takes:

and returns:

A page past the end returns an empty data list. Timestamps are ISO 8601 strings in UTC.

Endpoints

Agents

Query parameters for GET /agents, besides page, limit and projectId:

Agents are ordered by name, then by ID.

Agent tags are not returned.

Governance profiles

GET answers 404 when the agent has no governance profile. See Evidence Collection and Compliance for what the fields mean.

Update a governance profile

Send only the fields to change. At least one is required, and unknown fields are refused with 400.

The response is the updated profile, in the same shape as GET. The profile must already exist; create it in the app. Coverage and framework compliance are recalculated as they are when you edit the profile in the app. If the profile has no use case evidence (for owner, purpose or stage) or no data governance evidence (for dataSources), the request answers 404 and nothing is changed.

Framework coverage

This is the per-framework block of the governance dashboard. It returns one entry for each framework (EU_AI_ACT, ISO_42001, NIST_AI_RMF, SOC_2, ISO_27001, NIST_CSF_2), or an empty list when no agent in the project has a governance profile. It is not paginated.

A requirement counts as completed when every agent with a record for it has it complete, as partial when it has records but not all are complete, and as a gap when no agent has a record for it.

Guardrail policies

Guardrail policies are set per agent. There is no project-wide policy. See AI Guardrails.

GET /guardrail-policies takes enabled (true or false) to filter on whether real-time enforcement is on, besides page, limit and projectId. Policies are ordered by agent name, then by ID. GET /agents/{agentId}/guardrail-policy answers 404 when the agent has no policy.

Create or update a guardrail policy

Send only the fields to change. At least one is required, and unknown fields are refused with 400.

The response is the saved policy, in the same shape as GET. The agent must exist in the project. If it has no policy yet, one is created from the app's defaults: real-time enforcement off, Audit Only, no labels and a confidence threshold of 0.5. Settings the API does not manage, such as the Scheduled Detection schedule, PagerDuty alerting and custom detectors, are kept as they are. The SDK policy cache is refreshed, so SDKs pick up the change on their next policy lookup.

AI tool registry

Query parameters, besides page and limit:

Catalog tools are the approved Tool Registry entries visible to the organization; where the organization has its own version of a tool, that version is returned. Custom apps are the organization's internal AI apps and tracked apps. Tools are ordered by display name, then by ID.

Detection rules (URL patterns, API hosts, bundle IDs, paths), intercept patterns, request notes, who requested or approved a catalog entry, and any device, user or usage data are not returned.

Sanctions

GET takes status (SANCTIONED, TOLERATED or UNSANCTIONED) besides page and limit. Only tools that have a sanction set are listed. Sanctions are ordered by tool name.

Set a sanction

The sanction applies to the whole organization. As in the app, riskLevel and note are replaced on every write, so leaving them out clears them. The change has the same effects as in the app: cached usage reports are refreshed and, while Warn mode is on, browser extensions pick up the new policy on their next check.

Model approvals

status filters on approved or not_approved, besides page and limit. Only models with an approval record are listed; models never reviewed are not. Records are ordered by when they were created, oldest first.

Approving or revoking models is done in the app.

Rate limit

Each API key can make 60 requests per minute across all governance endpoints by default. Your ANTS administrator can set a different limit for the deployment.

Above the limit the API answers 429 with these headers:

and this body:

Requests refused before the limit is checked (404, 401, and the 403 key, mode and permission checks) do not count. If the rate limiter cannot be reached, reads are still served, and writes answer 503 so that no write goes through without a limit.

Errors

Errors return a JSON body with a message field and an error field:

A 404 is used for every "not available" case, so a caller cannot tell from outside whether the API exists for an organization. When the deployment has the API on, an invalid key gets 401 before the organization settings are checked.

Auditing

Every request that returns data or changes data is recorded in Audit Logs. The actor is the API key. Refused requests are not recorded.

Reads. Each successful read writes one entry, with no sampling, before the response is sent. If the entry cannot be written, the request fails with 500 and no data is returned.

So for any key you can see which project and which records were read, and when.

Writes. Each change is saved in the same database transaction as its audit entry. If the entry cannot be written, the change is rolled back and the request fails with 500.

A profile update that changes both the risk tier and other fields writes both entries in one transaction.

Settings. Turning the API on or off and changing the access write an entry with resource type governancePublicApi and action governancePublicApi.enable, governancePublicApi.disable, governancePublicApi.modeReadWrite or governancePublicApi.modeReadOnly, with the user as actor and the settings before and after. Turning Governance write on or off for a key writes an apiKey entry with action governanceWrite.grant or governanceWrite.revoke.

For organization keys, the Actor column shows the key's ID rather than its public key.

Limits

Never returned by any governance endpoint: prompt or response content, trace input and output, detection evidence text, secrets and credentials, API keys, device identifiers, user activity and agent tags. Governance profiles do not include the other evidence categories (human oversight, security, bias, transparency, legal accountability), attestations, requester and approver user IDs, or document links. Guardrail policies do not include PagerDuty or schedule settings.

Not available through this API; use the app:

• Turning the API on or off, changing its access, and allowing a key to write.
• Creating or deleting governance profiles, editing other evidence, attestations, and the review workflow (submit, approve, request changes).
• Drift alerts, policy violations and guardrail detections.
• Deleting a guardrail policy, and its schedule, PagerDuty and custom detector settings.
• Clearing a sanction. Set it to UNSANCTIONED instead.
• Approving or revoking models, and the model and framework catalogs.
• Adding, editing or requesting AI tools and custom apps.
• Discover AI usage, users, devices and enrollment.
• Budget AI keys, budgets and model groups.

Traces, observations, sessions, scores, prompts, projects, memberships and the other resources listed in the API Reference are available through the rest of the public API.

Next steps

• Authentication
• API Keys
• Audit Logs
• AI Guardrails