Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Verify That an Agent Connection Was Actually Granted?

Only if the service that receives the grant checks the grant itself: its scope, its term and the name of the person who approved it, against a key or policy the requester cannot edit. Ask what is checked and what happens when the check fails, then present a grant that should be rejected.

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

For the admin who signs off on agent access, a table that lists a connection is a claim rather than a check. Whoever can write to the table can make an agent look connected, and the credential arrives before anyone compares the two. Verification moves the decision to the component that hands over the credential: it reads the grant, tests it against something the requester does not control, and issues nothing when the test fails. Whether a tool does that is a question about its evidence rather than its dashboard, and the vendor pages reviewed here answer it in different amounts of detail. The question is worth asking of any tool that offers a connection screen, because the answer is usually a term rather than a test. The documentation reviewed covers scopes, terms and approvals, and on the page's own record a forged grant is refused only where a check stands at the token settings page, so a team should run the four-variant test, which takes an afternoon. One record type runs through it: a connection request for a single repository's token settings page. The credential a forged grant is after is the same one that ends up in a commit, so the check has to happen before the value moves.

Key findings

  • AWS's AssumeRole reference says the call "Returns a set of temporary security credentials that you can use to access AWS resources," and that "The resulting session's permissions are the intersection of the role's identity-based policy and the session policies," so the bounds of a session are written where the party receiving it can read them (AWS, 2026).
  • OpenAI's cloud environment page states that credentials "are only available to setup scripts" and that "secrets are removed before the agent phase starts," while environment variables are set "for the full duration of the chat," so what a connection carries depends on which phase is inspected (OpenAI, 2026).
  • Cognition's Devin guide states that a session credential is "scoped purely to the current session and are not saved for any future sessions," which documents where one scope ends and says nothing about what the model reads (Cognition, 2026).
  • Least privilege scopes the actions and credentials available to an agent, and it leaves the content of the screen alone, so a grant that checks out still says nothing about what the model read (What Is Least Exposure?).
  • The tether describes authority rather than capability: it says where an agent may go, and it does not say what the agent saw at each stop (What Is a Tethered Agent?).

What does an agent connection actually grant?

The scope comes first, because a connection means different things on different surfaces. On a rendered page, a governed browser environment covers what an agent reads and does: a dashboard, a cloud console, a settings page, an issue page or a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A grant for a shell command is enforced by a sandbox, and a grant for an API call by the service that issues the credential; neither is a page the model reads.

On the page, a grant is a statement about authority. It names the agent, the resource, the one action permitted, the term, and the person who approved it. Verification is the separate step that asks whether the component handing over the credential checked that statement before it acted. A grant can be written carefully and never checked, and a check can run without anything being written down.

That is where the usual vocabulary stops. Least privilege narrows the actions and credentials available to an agent, and it does not narrow what a page shows the model (What Is Least Exposure?). A connection that verifies tells a reviewer what the agent was allowed to do, not what it saw while doing it. The tether describes authority rather than capability, so it can say where an agent may go without saying what it read at each stop (What Is a Tethered Agent?).

The record type for this page is a connection request for one repository's token settings page, presented with a forged grant.

What separates a checked grant from a row in a table?

A row records that someone wrote it. A check is performed by the party that relies on it, at the moment of use, against something the requester cannot change. Three questions sort a tool: what is tested, what it is tested against, and what happens when the test fails.

AWS's reference shows a service that states its own bounds. The session's duration "can range from 900 seconds (15 minutes) up to the maximum session duration set for the role," and a session policy narrows the permissions at the same call (AWS, 2026). A recipient can attempt an action outside those bounds and watch it fail.

Browserbase's Contexts page describes the opposite default: "Once created, a Context persists until you explicitly delete it or it becomes invalidated" (Browserbase, Contexts, 2026). A session that persists is a standing connection. A single login that bundles workflow access with value access is the same problem, excessive agency by construction rather than by intent (How Do You Give AI Agents Access to Workflows Without Exposing Sensitive Data?).

NIST's zero trust guidance supplies the principle that makes a table insufficient: zero trust grants no implicit trust to assets or accounts "based solely on their physical or network location" (NIST, 2020). An admin table is a location, and a check that reads it trusts the place where the claim is stored.

The table is still worth reading before a test. It is not evidence that the grant was checked, and a reviewer who treats it as evidence has verified the record keeper rather than the connection.

What do the vendors themselves say?

Cognition's Devin guide lists four credential scopes, organization, personal, repository and session, and says a session credential is "scoped purely to the current session and are not saved for any future sessions," which fixes when one scope ends and says nothing about what the model reads. The same page adds that "In the browser, Devin types the value directly" and that "All secrets are encrypted at rest," while whether the model sees the value it types is not described in the pages reviewed (Cognition, 2026).

OpenAI's cloud environment page, marked legacy, states that credentials "are only available to setup scripts" and that "secrets are removed before the agent phase starts," while environment variables last "for the full duration of the chat (including setup scripts and the agent phase)," and "Setup scripts run in a separate Bash session from the agent" (OpenAI, 2026). Those are three different windows for the same value, and the page does not say which component tests the boundary between them.

1Password and Browserbase describe an approval attached to the use of a credential: "Secure Agentic Autofill allows AI agents to authenticate with web services without ever exposing credentials," and "Credentials are not shared with the LLM or exposed in Browserbase logs and repos," a claim about the design rather than a description of the mechanism (1Password and Browserbase, 2025). The release also lists "Human-in-the-loop authorization: Real-time approval prompts via 1Password mobile or desktop," with no technical detail on how the injection is implemented.

Dimension Cognition Devin, per its documentation AWS Security Token Service, per its documentation What a buyer should verify
Unit of scope Organization, personal, repository or session A role, narrowed by a session policy That the grant names one agent and one resource
Term The current session, for a session credential 900 seconds to the role maximum, one hour under role chaining Where the number is set and what event ends it
Where the value lives Typed into the browser, or bound as an environment variable Returned by the service as a temporary credential Which component holds it, and whether the model sees it
Approval Not described Not described A named person, written into the record
What the page proves That a scope was chosen That a session was issued inside a policy What the receiving service tested before issuing it

The last row is the one that matters: a scope and a policy are terms, and a term becomes evidence only when something checks it against the request in front of it.

What does a forged grant look like when it is rejected?

The record is a connection request for one repository's token settings page: an agent asks to write a deploy key, and the request arrives with a grant naming an agent, a repository, a write, a term and an approver.

The service that holds the credential reads the grant and tests it against the key it holds for the account that issued it. The forged grant fails on two counts, and either is enough. The signature does not verify, so the grant was not issued by the account it names. The approver does not appear in the approval record, so no person approved the write. No credential is returned, and the refusal is recorded with the grant's identifier.

A table lookup would have accepted it: the request was well formed, it named a real repository, and a row claiming the connection could have been written by anyone with access to the table. Verification asks what the recipient tested; a lookup asks what someone recorded.

The identity on the grant is the second thing to test, because a valid grant to the wrong identity is its own kind of forgery. Google's guidance for Workspace administrators says the super admin account should be used only when needed, a rule written for people that applies with more force to an agent (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?). The credential a forgery is after also ends up in commits: GitGuardian counted "28,649,024 new secrets exposed in public GitHub commits across 2025" (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

How would a team test whether a grant is really checked?

Name one agent, one action on one page, and one grant. Then present four variants and write down what the service did with each: a grant whose term has passed, a grant scoped to a different repository, a grant whose approver is missing from the approval record, and a copy of a valid grant presented a second time. A checked grant refuses all four.

Variant presented What a checked grant does What a table lookup does
Term has passed Refuses, and no credential is issued Issues, unless the row was edited
Scoped to another repository Refuses, because scope and action do not match Issues, because the row names the agent and not the page
Approver missing from the record Refuses, because the name cannot be found Issues, because the field was filled in
Valid grant replayed Binds it to one run, or refuses it Issues, for as long as the row exists

The reason to run the test is the credential, not the connection. Sonatype's release puts "56% of the malware discovered in Q1 2025 was related to data exfiltration," a "dramatic increase from 26% in Q4 2024" (Sonatype, 2025). Verizon's 2026 Data Breach Investigations Report says breaches now "start with software vulnerabilities, beating stolen passwords as the top way attackers get in," and that "Hackers are shifting their focus from tricking people to exploiting systems" (Verizon, 2026).

Verification of authority also has a ceiling. A connection that checks out can still be steered: an environmental injection attack on generalist web agents reached an attack success rate of up to 70 percent in stealing users' specific personal information (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?). And a compromise that enters through one agent is not contained there: web-delivered attacks made GPT-4o multi-agent systems execute malicious code in 58 to 90 percent of trials (How Do You Protect Sensitive Data Across Multiple AI Agents?).

So the test has two outcomes to record: whether the credential was refused, and what the model had already read.

What does a governed environment change?

A governed environment is a control class that decides what a model may see and who must approve what it does, and both halves leave evidence a recipient can check. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so a token settings page renders with a placeholder where the credential sits. Real values resolve only at the approved destination, at the moment an action is approved. A named person confirms the policy and approves each consequential action, and a write to a token setting is one. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this page's question, that changes what verification rests on. A table can be edited by the party being checked. A record written as the run happens, naming the screen and the person, is a different kind of evidence, and it is the kind a reviewer can test later. The grant still has to be checked by the component that hands over the credential; the record is what lets someone confirm afterwards that the check happened, on which page, and for whom.

The two answer the title together: the check is the moment, and the record is the proof. Neither substitutes for the other, since a record of an approval that no component enforced is a diary, and a check that leaves no trace cannot be reviewed.

The scope is the rendered page. The governed environment does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a grant for a shell command or an API call is enforced by the sandbox and by the service that issues the credential, and a reviewer who needs evidence there has to ask those components.

Methodology and limitations

This page rests on vendor documentation from Cognition, OpenAI, Amazon Web Services, Browserbase, and 1Password with Browserbase, on NIST guidance, on two industry datasets, and on existing research pages. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quoted facts appear in the wording the page uses, and a figure is cited as its publisher reported it rather than as an independent measurement of the risk described.

RedactSure did not test any of the products hands-on. Where this page says a behavior is not described in the pages reviewed, it means the recorded material for that page does not cover it, and a vendor's own documentation is the only source here for what that vendor does. The 1Password and Browserbase release is an announcement rather than a specification, and it is cited for what it states and not for how the mechanism works. Vendor features change, and the page carries its date, so a release after October 21, 2026 is unreviewed until the test above is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a connection request for a repository's token settings page, and not an organization.

Determinations about whether an access design meets a contractual, regulatory or audit 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 a grant it should not hold, repeated after each change to the tool that issues it, and a result recorded without the date of the release it ran against tells a reviewer little.

What the record shows

Four vendor pages describe what a connection carries, and none describes the check that would make it verifiable: a scope on a credential, a phase that removes credentials before the agent runs, a session with a stated term, an approval attached to use. Each term is inspectable in its own documentation, and each is written by the party being checked. The evidence that holds is the check at the point of use plus a record of the action, which is the one thing none of these pages describes. The title asks whether something other than the requester's own word stood behind the credential, which an intended connection or an existing row cannot show. One grant the agent should not hold, presented on one page, is the whole test: present it and watch whether any credential follows.

Frequently asked questions

How do I verify that an agent connection was actually granted?

Ask the component that hands over the credential what it checks, then make it refuse something. A verified grant is tested at the point of use against a key or policy the requester cannot edit, and the refusal leaves a record. A connection that appears only in an admin table has not been verified by anyone. The practical check is a variant that should fail: an expired term, a wrong resource, or an approver who is not in the approval record. Ask for the refusal, not the assertion.

Is a row in an admin table proof that a grant exists?

No. A row records that someone wrote it, and anyone with write access to the table can add one. That is enough for an inventory and not enough for a credential. Proof comes from the receiving service: what it tested, what it tested against, and what it did when the test failed. Ask to see a refusal in the record, since a system that has never refused anything has not been tested. The row and the check are different objects.

What should a grant contain so that it can be checked?

One agent, one resource, one action, a term, and the person who approved it. Those fields have to sit inside the artifact the service checks, not in a note beside it, because a field the requester supplies is a field the requester can change. The service also needs something of its own to check the artifact against, such as a key it holds or a policy it reads. Without that, the grant is a description. Name the key the service holds, or the check cannot happen.

What does a forged grant look like?

Usually well formed. It names a real agent and a real repository, and it carries a plausible term and an approver's name. It fails on the part the recipient can test: the signature does not verify against the key held for the issuing account, or the named approver is absent from the approval record. A forgery that a lookup would accept is the ordinary case, which is why a test has to include one. Present one and see what the service does.

Does verifying the grant tell me what the agent read?

No. A grant governs what an agent may do, and the screen it read on the way is a separate question. An agent can hold a valid grant and still have received every field that a settings page rendered. Verification answers authority, and exposure needs its own control at the point where the page is drawn. Ask both questions, and ask them of different components, because authority and exposure have different owners.

What would a security team ask a vendor in writing?

Which component checks the grant, what it checks against, and what happens on a failed check. Whether the approval is written into the artifact or held in a table the vendor can edit. What the model receives on the page where the credential is used. And what record a reviewer can read afterwards, with the screen, the action and the approver's name. An answer that describes a dashboard rather than a check answers a different question. A dashboard describes; a record proves.

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 Makes a Granted Connection Leave Evidence

A permissions table records what was promised, and the designs reviewed, from scoped credentials to phone approvals, never record what the page showed at the action.

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

Before, the agent opened the token settings page, the model received the field as rendered, and a table row was the only evidence. Inside, the field renders as TOKEN_001, the save stops for the platform lead, and the record holds that screen and the approval with a name.

RedactSure is deploying now with enterprise and government customers. Sonatype found data exfiltration behind 56% of the malware it recorded in the first quarter of 2025.

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

See it on your own workflow

A connection no one can show was granted is one an auditor will question. Bring a connection your team sets up and see, with test values, the record that holds the screen and the named approval. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.