Approved Destinations: Where Agents Send Data
Approved destinations let an Organization decide which model endpoints, providers, hosts and email recipients its AI agents may send data to, and flag the first time an agent reaches somewhere new.
In the guarded v2 execution profile, an unapproved destination is refused. An action review cannot supply its missing destination authority or disclosure budget. Approve the destination through policy controls and configure finite budgets before requesting action review. See deployment gates for qualification requirements and limits.
Use Governance → Policies → Approved destinations to say where your agents may send data, and to see in Governance → Evidence → Data flow whether each captured destination is approved. This feature is available when your deployment administrator enables it. Monitor records and alerts. Deliberately activated protection checks covered destinations before dispatch and refuses unsupported execution paths. Guarded execution requires exact-release operator qualification and a blocking destination baseline; Monitor alone cannot authorize external agent work. See Availability and deployment gates.
Owners, Admins, and Security Admins can turn monitoring on, approve, edit, revoke, and review. Agent Admins and Auditors can read the page and the chips. Changes need a recent sign-in. Monitoring is off for every Organization until you turn it on.
What you can approve
| Class | What an approval names | Example |
|---|---|---|
| Model gateway | An endpoint identity: provider type, partition, Region or Azure resource, and optionally account, deployment, inference scope, and network path | AWS Bedrock, commercial, us-east-1, in-Region only |
| Model provider | A provider name a router reports, with aliases | Together, alias Together AI |
| Host | An exact host name, or *.example.mil for its subdomains (never the bare domain) | *.agency.mil |
| Recipient | An email address, @domain, a phone number, or a Discord channel | @agency.mil |
A gateway approval constrains only the fields you fill in. Leave account blank to approve any account in that Region; fill it in to approve one. If the platform cannot see a field you constrained, the destination stays unapproved and says which field it could not confirm. Bedrock approvals always name the partition and Region, and Azure approvals name the partition and resource.
What the platform can see for each provider:
| Provider | Seen from the request | Not visible |
|---|---|---|
| AWS Bedrock | Region and partition from the endpoint host, private endpoint (vpce), whether the model ID is in-Region, a geographic or global cross-Region profile, or a profile ARN, and the account when you configured a role ARN or used an ARN model ID | The account for access-key connections without a role; which Region served a cross-Region request |
| Azure OpenAI | Resource name, Azure commercial or Government cloud (from the DNS suffix), and deployment name | The resource's Azure region, whether the deployment is Global, Data Zone, or regional (record this in posture notes), and private link use |
| OpenAI, Anthropic, Gemini | The provider endpoint | The account behind the API key |
| OpenAI-compatible and local servers | The server host and port | Anything beyond the host |
Platform-mode endpoints that set no base URL are identified only by provider name.
Turn monitoring on
- Open Approved destinations and choose Turn on monitoring.
- The page lists every destination your agents have already reached. They stay Unapproved so that you decide on each one. Approve all current destinations is available if you want a starting baseline; it needs a justification and records it on each approval.
- From then on, a destination first seen after activation is New, and the Organization security log records
destination_first_seen. If a model entry in Organization AI starts reaching a different endpoint identity (for example another Region, another Azure deployment, or a cross-Region profile), the log recordsdestination_identity_changedwith the previous identity.
Approving a destination needs a justification (up to 1,000 characters) and can have an expiry. An expired approval is treated as revoked and the pattern becomes available to approve again. Revoking returns the destination to Unapproved.
Data flow chips
| Chip | Meaning |
|---|---|
| Approved | Matches an active approval |
| New | First seen after monitoring started, not yet approved or reviewed |
| Unapproved | Not approved: seen before monitoring started, reviewed without approval, or approval revoked |
| Unidentified | The platform did not record an identity, so it cannot be approved |
| Not evaluated | Peers, inbound sources, and other counterparties this feature does not govern |
Filter Data flow by approval state, and use Approve… from a destination's details. Approval state covers only destinations Data flow captured; the existing coverage notes still apply, including browser subrequests and legacy sandbox traffic.
Provider posture notes
On a gateway or provider approval you can record jurisdictions, processing regions, retention and training answers, deployment type (for example "Azure Data Zone Standard"), attestations with references, and a review date. These are administrator-attested: the platform does not check them, fetch anything to confirm them, or change behavior because of them. Overdue reviews and expired attestations are flagged.
Alerts and your SIEM
Destination events reach your SIEM when audit forwarding is enabled. By default an event carries the destination class, state, first agent, and, for gateways, model providers, and hosts, the destination identity. For recipients it carries the email domain only. Your installation operator can set ORGANIZATION_SECURITY_DESTINATION_TELEMETRY=strict so that events carry only an ID, class, and state, or ORGANIZATION_SECURITY_DESTINATION_FULL_RECIPIENTS=true to include full addresses. Sentinel deployments must add the new columns before upgrading; see the audit bridge guide.
Limits
- Monitor does not block. Protected modes use the explicitly activated coverage profile below. Security rules, credentials, contact policy, network restrictions, licensing and security holds remain independent requirements.
- GovCloud and Azure Government identities are supported but have not been validated against a live environment.
- The first-seen register is metadata and follows your metadata retention period. A destination that ages out can reappear as New.
Optional: OpenRouter guardrails
If your Organization routes through OpenRouter, one request can be served by many providers, and approving the gateway does not approve them. OpenRouter's own account controls can serve as an independent ceiling: use a separate OpenRouter account per Organization, set a guardrail provider allowlist that matches the providers you approved here, and require zero data retention where your policy demands it. The platform never reads or changes those settings, so keep them in step manually. Request-level provider pinning is not part of this feature.
Destination protection
The mode is Organization-wide. Monitor records observations and cannot authorize guarded external execution. Block unapproved destinations and Require approval both require every destination to match a current approval. Complete action review applies at supported boundaries when automatic disclosure review requires it and no scoped processing grant covers the action. Unknown identities and unsupported holds deny.
The current profile, Platform dispatch protection v2, checks explicit Organization model gateways (including retries and auxiliary calls), final prepared HTTP requests and every redirect hop, OpenAPI requests with current fixed credentials, final managed email recipients/transport and webhooks/callbacks. Token refresh and managed TLS identities need separate adapter qualification; renew expired credentials before review. Browser/fetcher, sandbox/custom code/local MCP, remote MCP, platform model fallback and unadapted native paths refuse while protection is active. Platform conversations (web/MCP replies and internal agent messages), storage and infrastructure keep their separate access controls. Third-party internal routing/forwarding remains outside the guarantee. Response-only serving-provider labels are observations, not prospective checks.
The page shows requested/effective mode, generation, implemented/enabled/activated/validated coverage and exclusions. Unavailable prerequisites block protected work. An operator verification session is separately labelled Verifying and is never qualified customer coverage.
Before activation, review observed destinations, configured model routes/failover, token services and infrequent schedules; run representative workflows and review shadow would-deny results. History is incomplete. Review legacy entries with explicit protocols/ports, email recipient channel and configured-role versus model-resource account identity. HTTPS defaults to port 443; wildcards exclude the apex. Posture notes are attestations and change no enforcement behavior. Approving private hosts grants no network permission.
Activation requires operator validation, compatible upgraded/drained processes and deliberate publication by an Owner, Admin or Security Admin with a recent sign-in, current generation, profile and justification. Monitoring and visibility toggles do not disable active protection.
Approve destination authorizes future use. Approve this action once authorizes one identical frozen action at a supported boundary and leaves the destination register unchanged. It cannot supply missing capability, credential, destination or budget authority. Authorized reviewers use the existing approval queue and recent sign-in; owner separation, expiry and cancellation apply. Approving never executes. Changed body/headers/destination/credentials or additional initiating principals need a new decision. Redirects and models cannot create a destination action hold; stored OpenAPI and Outbox actions use their own mandatory complete review. Browser and arbitrary MCP execution remain excluded. Unreviewable, opaque, oversized or credential-bearing body/query requests cannot hold. Authorization headers stay masked and bound to the exact request.
Denials explain whether approval is missing, identity is unavailable, coverage is unsupported or enforcement is unavailable. Review the shared finding and effective coverage with an authorized administrator; approve a legitimate future destination deliberately or choose a covered path. A resolved finding alone grants no authority.
Revocation prevents new admissions. Earlier admitted operations may start or finish afterwards; use halt controls for incident containment. Unknown outcomes require reconciliation and never automatically replay. Changing to Monitor requires authorized audited publication, cancels unused grants and leaves guarded external work setup-required; it does not resend denied work.
Recovering from an uncertain attempt
An action with an Unknown outcome may already have taken effect. Identical requests remain blocked even if you subsequently approve the destination. In Actions needing a decision, an authorized reviewer other than the agent owner can select Allow a new operation, after recent sign-in and a required reconciliation note. Check the receiver and original attempt first: the original operation may still finish, so another operation can duplicate its effects.
This decision preserves the original outcome and spent approval. It sends nothing and does not resume the agent. Start any intended new work deliberately; it must pass current policy and obtain a fresh action approval when required. Resolving the finding alone does not release the retry barrier.