Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is an Approved Destination for AI Agent Output?

An approved destination is a named service and resource where the environment releases a real value on the agent's behalf: the repository's API, the vendor's form, the bank's submit. Everywhere else receives a placeholder, so ask which destination a tool names and who approves the release.

A credential reference travels from a browser record through a bounded route to a separate API destination.

For an organization whose agents move customer data between screens, a destination is approved when the organization has decided in advance, and by name, that a real value may appear there. The decision is narrower than access and narrower than permission: an agent can reach a hundred services and still be approved to release a customer number at one of them. Agents make the distinction urgent because they carry values between screens at speed, and a value that lands in the wrong field is a disclosure, whatever the permissions allowed. The closest documented controls govern callers, routes and actions, so the destination is a decision a team has to make, record and answer for itself. What Is Least Exposure? sets out why the content of a screen, and not only the scope of an action, is the unit to govern. The term matters most where an agent hands a value to a form, because a form is where a placeholder and a real value look identical in a transcript. The record below is one run: two destinations, one approval, and a written answer to which page received what.

Key findings

  • SecretBench is "a labeled dataset of source codes containing 97,479 secrets (of which 15,084 are true secrets)," and each of those is a value that reached a place nobody approved (Basak et al., 2023).
  • Wiz's review of the Forbes AI 50 found that "65% had leaked verified secrets on GitHub," and a repository accepts whatever a token with write access sends it (Wiz, 2025).
  • GitHub documents its masking command for logs, telling teams to "Mask all sensitive information that is not a GitHub secret," a control applied after a value enters a run and not to the page that receives it (GitHub, 2026).
  • OWASP's non-human identity list describes NHI2 secret leakage as "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores," which names an unapproved destination without using the term (OWASP, Top 10 Non-Human, 2025).
  • A named destination turns a vague instruction into a testable one: the value may appear on this page, in this field, and nowhere else in the run (What Is Least Exposure?).
  • When the substitution happens before any model reads the screen, the model works on a consistent token such as TOKEN_004 and the approved destination receives the real value at the moment of the approved action (What Is Render-Layer Tokenization?).

What does a governed browser environment cover for a destination?

A governed browser environment covers what an agent reads and does on a rendered page: dashboards, consoles, settings pages, issue pages and forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. That boundary decides which destinations are in scope here. A key typed into a credential field on a repository settings page is inside it. The same key exported into a shell session that calls the repository's API from the terminal is outside it, and the difference is the page, not the credential (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

The record for this page is one run with two destinations. An agent is asked to rotate a deploy key. It opens a repository's settings page, types the new value into the credential field and saves it. Later in the same run it opens a vendor's incident form and pastes what it takes to be the same value into a webhook address field, because the form asks for a signing secret. The policy names the repository's credential field as an approved destination. It does not name the vendor's form. Both are pages the agent renders, both are reached with the same credentials in the same session, and only one is allowed to hold the real key.

Two destinations, one approved. Nothing on either page tells the agent which is which. What separates them was decided before the run, by a person, and it is checked at the moment of the release rather than inferred from the address bar or from the certificate the connection carries.

What makes a destination approved rather than merely reachable?

A destination is approved when three things line up. The policy names a service and a resource, not a host and not a domain. The name is written before the run, so the agent cannot discover a destination and have it approved in the same step. And a named person approves the release at the moment the value is about to become real.

Firecracker's design document states that "All egress traffic from a guest is therefore considered untrusted, and should be filtered at the host-level," a filter on hosts that says nothing about which resource on a host may receive a value (Firecracker, 2026). A host filter cannot tell an issue page from the credential field on a settings page.

Identity narrows the caller, not the destination. Teleport's agentic identity framework states that "Your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key," which answers which workload is calling and not which resource may receive a real value (Teleport, 2026). OWASP's CI/CD guidance says to "Prefer using temporary credentials over static credentials" and to "Avoid sharing the same set of credentials across multiple contexts," both of which shorten and narrow a credential without naming a destination (OWASP, CICD-SEC-6, 2026).

So an allowlist answers where a packet may go, and an approved destination answers where a value may become real. An agent given cloud setup rights faces the same split between what it may call and what may see a value, as Is It Safe to Let an AI Agent Set Up Your Cloud Environment? sets out. The two answers can differ on one host, in one session, within one minute.

What do the vendors themselves say?

Four vendor pages describe a control a buyer might read as a destination rule; each limits something else: identity, lifetime, isolation or log content.

The same Teleport page lists "Comprehensive audit trails and behavior analysis for agent actions across infrastructure," an action record rather than a destination rule, and it marks most of its listed capabilities in progress or not started (Teleport, 2026).

Cognition's Devin guide states that "In the browser, Devin types the value directly," so a credential can reach a rendered page with the model holding it, and whether the model sees that value is not described in the pages reviewed (Cognition, 2026). The same guide scopes credentials to organization, personal, repository or session, with a session secret "scoped purely to the current session and are not saved for any future sessions," a lifetime and not a destination (Cognition, 2026).

GitHub documents that "secrets are not passed to the runner when a workflow is triggered from a forked repository," the closest thing to a destination rule on that page, since the credential is withheld from a run whose origin is not trusted (GitHub, 2026).

Firecracker says it "is designed to assure secure isolation using multiple layers," isolation between guests that does not decide what a guest may send where (Firecracker, 2026).

Dimension What the documentation states What a buyer should verify
Teleport Identity per workload, audit trails for agent actions, most listed capabilities marked in progress or not started Whether the identity is tied to a named resource, not only to a workload
Cognition Browser typing puts the value in the page; a session secret ends with the session Whether the model reads the value it types, and which page may receive it
GitHub Credentials withheld from runs triggered by a fork; masking applied to logs Which jobs and which pages inside the repository may receive the value
Firecracker Layered isolation between guests; egress filtered at the host level Whether the filter names a resource as well as a host

How does an approved destination differ from an allowed domain and an approved action?

Three controls get confused because each is described as permission. A domain allowlist answers where a request may go. An action approval answers what the agent may do. An approved destination answers where a real value may appear. A run can satisfy the first two and still put a signing secret on a page nobody named. An approval that reads "may file the incident report" says nothing about which values may appear in the report.

GitGuardian's State of Secrets Sprawl release, reported by CIO Dive, counts about 29 million credentials leaked on public GitHub in 2025, with AI-service credential leaks up 81% year over year, and quotes the company's chief executive: "AI agents need local credentials to connect across systems" (GitGuardian, 2026).

Sign-up and checkout forms are a measured leakage point, which is why an agent that fills one should not read the card (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?). An enterprise browser governs what a person copies, pastes, uploads and downloads on a managed device, as Enterprise Browser or Render-Layer Tokenization? sets out, and it does not name the resource that may receive a real value from a model.

What happens at a destination that is not approved?

The vendor's incident form takes TOKEN_004, submits, and stores a string that no service can redeem. The response says the webhook was saved, and the agent moves on. The failure is invisible at the moment it happens and shows up later, as a credential that was never leaked and a setting that will never work.

What the model holds decides what an injection collects. A study of agentic coding editors found that "attack success rates can reach as high as 84% for executing malicious commands," and an agent that holds a real value hands it to whatever the injected content asks for (Liu et al., 2026). An agent that holds TOKEN_004 hands over a string with no use outside the environment that issued it.

The same distinction applies below the page. Cognition's documentation adds that "For shell commands, it binds secrets as environment variables whenever needed," a path outside a rendered page and outside the destination policy this page describes (Cognition, 2026). A value in an environment variable has no destination until the command runs, which is why the rendered page is the unit that can be governed.

Under the minimum necessary standard at 45 CFR 164.502(b), an organization has to limit protected health information to what the purpose requires, and an agent that opens a patient chart can be given the chart as tokens while the filing destination receives the values (Can Staff Use AI on Patient Records Without PHI?).

What does a governed environment change?

A governed environment treats the destination as something decided in advance rather than discovered mid-run. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the model works on placeholders such as TOKEN_004 for the whole run. A real value resolves only at a destination named in policy, at the moment of an approved action. A named person confirms which destinations are approved and approves each release, and every release is written to a record that exports to the organization's own monitoring.

Applied to this page's record, that changes both destinations. The second form still submits and still says the webhook was saved, and what it receives is a string the environment will not redeem on any page. The approved field on the repository's settings page resolves the real key when the named approver confirms the save, so the value exists in two places only: the form the person approved and the record of the approval. The model's context holds the token on both pages, which is what makes a successful injection collect nothing of use.

The scope of that control is the rendered page. The terminal, the IDE, the local filesystem, direct API calls and MCP are outside it, and a value exported into a shell session is governed by the sandbox and credential store rules a team sets for its coding agent, not by a destination policy.

Three questions follow for any implementation. Which service and resource are named, and is the resource specific enough to exclude a neighboring page on the same host? Who approves a release, and can that person see the page, the field and the purpose? What record shows which destination received a real value and which received a token?

Methodology and limitations

This page rests on two research preprints on credentials in source code and on prompt injection in coding agents, vendor documentation from Teleport, Cognition, GitHub and Firecracker, two OWASP standards pages, two industry research releases, and existing RedactSure research pages. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Vendor pages are cited for what they say about custody, identity and audit, not for a term they do not use. Quoted facts are cited to the page that states them, and figures from industry research are cited as reported rather than independently measured.

RedactSure did not test any named product hands-on. The vendor pages describe identity, credential storage, log masking, workflow triggers and machine isolation; none of them uses the term approved destination, and the reading here compares those recorded facts with the term, stating the limit where one applies. Where this page says a behavior is not described in the pages reviewed, it means the recorded facts for that page and not a claim about the product. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, one run with two rendered pages and one approval, not an organization.

Determinations about whether a destination policy meets a contractual, card-scheme or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against its own pages, repeated after each release.

What the record shows

The two destinations in the record are the answer in miniature. One was named before the run and had an approver; the other was reachable, routine and unapproved, and it accepted a token. Each documented control reviewed above narrows something real: identity narrows the caller, a host filter narrows the route, an action approval narrows the verb, and log masking narrows what is written down. None of them decides which resource may receive a real value, and the counts from the industry research show values arriving at repositories and forms nobody named. RedactSure's environment is built on the destination as a policy object, which is one way to make the decision checkable afterward. Running one agent and one task against two destinations is the practical test, and for each page a team should ask which value it received, who approved the release, and where the record of that approval lives.

Frequently asked questions

What is an approved destination for AI agent output?

It is a service and resource that policy names in advance as a place where a real value may appear, at the moment a named person approves the release. The name has to be specific: a host or a domain is not enough, because one host holds public pages, private settings pages and forms. Everywhere else the agent reads should receive a placeholder. The test is whether the tool can name the page, the field and the approver before the run begins.

How is an approved destination different from an allowlist?

An allowlist governs the route a request may take. It names hosts, ports or domains, and a host can hold hundreds of resources. A destination governs the value: whether the real string or a token arrives on that page. A run can stay inside every allowed host and still put a signing secret on a form nobody approved, which is why the two are not substitutes. Ask which of the two a tool implements before asking how it is configured.

Is a page the agent only reads an approved destination?

No. Reading is where exposure starts, not where a value is released. A page the agent reads is governed by what the model is shown, which is the tokenization question. A destination is the smaller set of pages where a real value may resolve, and it usually includes a submit button, a save action or a field the organization depends on. Keep the two lists separate, and write down which pages belong to each. A read-only settings page can still leak, because the model reads what it renders.

What does the agent see when a destination is not approved?

A placeholder, such as TOKEN_004, that the environment will not redeem on that page. The form still submits and may report success, so the failure is quiet: a setting is saved that will never work, and no value reaches the vendor. The model's context holds the token rather than the credential, which limits the damage if injected content asks the agent to send what it has. Check the page after the run as well as the transcript. The vendor may log the attempt, so read that log too.

Who should approve a release to an approved destination?

A named person who can see the page, the field and the purpose of the value, and who is accountable for the result. A role or a queue is not enough, because an approval with no name cannot be reviewed later. That person should also confirm which destinations exist, since a release and a policy are the same decision at different moments. Write the name into the record at the time of the release.

What should a buyer ask a vendor about destinations?

Ask for the list of named destinations, whether each is a host or a specific resource, who approves a release, and what record shows which value reached which page. Ask what the model sees on an unapproved page and how the tool treats a shell, an API call or a code editor, since those sit outside a browser control. An answer the documentation does not support is unanswered until a run confirms it. Ask for a sample record from one run, with the names removed.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Names the One Destination That Gets the Real Value

Every value an agent carries lands on a page, and the controls above leave the choice of page to the run, so a page nobody approved satisfies each.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the agent holds the deploy key and pastes it into a vendor's form nobody approved. Inside: the model reads TOKEN_004 on both pages, the key resolves on the repository field when the owner approves, and the vendor form stores a string the environment cannot redeem.

RedactSure is deploying now with enterprise and government customers. Wiz found that 65% of the Forbes AI 50 had leaked verified credentials on GitHub.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

An approved destination decides where a real value can land when the agent pastes it somewhere else. Bring a task with a form submission and see, with test values, what an unapproved form would store. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.