Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Why Should the Developer's Private Key Be the Root of Authority for Agents?

Because the developer is the party who can be held to the grant and the one the credential owner consented to; a vendor-held key makes the vendor the authority, so a breach of the vendor is a breach of the authority itself. Ask where the signing key lives and what a vendor compromise would yield.

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

The key that matters in an agent deployment is not the token the agent presents. It is the key that signs the grant the token is issued under: the statement of which agent, on which task, may reach which destination, for how long, and under whose name. Whoever holds that signing key can create authority for actions nobody approved, which is why the choice between a developer-held key and a vendor-held key is a question about accountability before it is a question about cryptography. A vendor that holds the root can mint a grant for any customer's agent. A developer who holds it signs a scope, and the signature can be checked against a public key the organization already pins, so verification does not depend on the vendor's goodwill. This page defines the root, sets out why it belongs with the developer, reads five vendor pages on identity, credential custody and approval, and then follows one record type, a repository settings page that displays an agent's deployment grant, through the case the design is built for: a vendor compromise with no root to steal. The scope is the rendered page; the signing key itself stays with the developer, and the terminal, the IDE, the local filesystem, direct API calls and MCP are outside what the control class covers.

Key findings

  • 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"; the page marks most listed capabilities "In-progress" or "Not started" and gives no certificate lifetime (Teleport, 2026).
  • 1Password and Browserbase state that "Credentials are not shared with the LLM or exposed in Browserbase logs and repos," which keeps the value out of the model while leaving it in the vendor's vault, the thing a breach would have to reach (1Password and Browserbase, 2025).
  • Verizon's 2026 report records that breaches "now start with software vulnerabilities, beating stolen passwords as the top way attackers get in," the path that matters when one system holds signing authority for many customers (Verizon, 2026).
  • Cursor's documentation states that "All MCP connections need your approval" and that "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues," an approval that says nothing about how a credential is stored (Cursor, 2026).
  • A governed environment replaces values on a rendered page with consistent tokens before any model reads the screen, so an agent works the settings page as GRANT_014 and DEPLOY_002 rather than the grant and the key it names (What Is Least Exposure?).
  • Real values resolve only at the approved destination, at the moment of an approved action, and a named person approves each consequential action, so a deployment's authority traces to a person and a signed scope (What Is a Tethered Agent?).

What does it mean for a private key to sit at the root of an agent's authority?

A grant is a statement, signed by a key, that an agent may do a named thing: reach a destination, use a credential, change a record, for a stated period. The key that signs it is the root, because every other permission in the run derives from it and nothing above it exists to overrule it. The agent's working token is not the root. It is a short-lived instrument issued under the grant and useless without one.

A credential can be rotated, a session revoked, a token expired. None of that helps if the party that compromised the vendor can sign a new grant. The root decides who can create authority, not who can use it.

The scope of the control class follows the same line. What a governed browser environment covers is the rendered page: what the agent reads and does on dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. The signing key is not a value the agent reads on a page; it stays with the developer, outside the browser environment.

The worked record for this page is a repository settings page that lists an agent's deployment grant: the environment it may deploy to, the scope, the expiry and the name of the approver. The page is rendered to the agent, and the question at each step is what the model received from it and which key made the grant valid. AWS's guidance strongly recommends not creating access keys for the root user, the cloud version of the same rule against durable top-level authority a compromise can reach (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?).

Why should the developer hold that root rather than the vendor?

The case is accountability, and it runs along the consent chain. The credential owner, the person or team whose data the agent touches, granted access to a named developer or team. They did not grant it to a vendor and cannot hold a vendor to a task it never saw. When the root sits with the developer, the signature on a grant is the developer's, the scope is the one the developer reviewed, and the party who answers for an over-broad grant is the party the credential owner already trusted.

A vendor-held root moves that authority outside the chain. The vendor can mint a grant for any tenant's agent, and a compromise of the vendor is then a compromise of the authority, not of one credential. Google's guidance for Workspace administrators, noted on Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?, says that the super admin account should be used only when needed, a rule written for people that applies with more force to a system that can create authority for an agent.

A law firm's summary of FINRA's 2026 oversight report flags that "Agents may act without human validation and may take actions that exceed the user's actual or intended scope or authority," which is the accountability gap a vendor-held root leaves open, since the vendor is not the party the credential owner consented to (Debevoise & Plimpton, 2026).

Question Vendor-held root Developer-held root
Who can mint a grant Vendor staff or vendor systems, for any tenant Only the holder of the private key, for the scopes that key signs
What a vendor breach yields The ability to sign new authority Sessions and grants that were already signed
Who can revoke Whoever operates the vendor's console The developer, without the vendor's cooperation
Whose name is on the approval The vendor's, or a customer admin acting in the vendor's console The developer named in the consent
What the record proves That the vendor's system allowed the action That a named person signed this scope
Where the key lives Vendor infrastructure The developer's device

The table is also the test to run against a vendor's documentation: for each row, find the sentence that answers it, and treat a row with no sentence as open rather than settled.

What do the vendors themselves say?

The pages reviewed describe identity, custody and approval. None describes a root key held by the developer. Each paragraph states what the vendor documents and the limit its page carries.

Teleport's framework page says an agent's identity should be "verifiable" and tied to where it runs rather than a shared API key; most listed capabilities are marked "In-progress" or "Not started," and no certificate lifetime is given (Teleport, 2026).

1Password and Browserbase's release states that "Secure Agentic Autofill allows AI agents to authenticate with web services without ever exposing credentials," with approval through 1Password's mobile or desktop app; the credential stays in the vendor's vault, which can release it, and the release gives no technical detail on the autofill (1Password and Browserbase, 2025).

Composio's documentation states that "Credentials never pass through your app or the model," and that "The user signs in on the hosted link and Composio stores the resulting connected account," leaving the account in the vendor's hands, with encryption and physical storage not described (Composio, 2026).

Cursor's page states that "By default, terminal commands need your approval" and calls its run modes "best-effort guardrails rather than a hard security boundary," without saying how credentials are stored or protected (Cursor, 2026).

OpenAI's Codex page states that "Locally, Codex uses an OS-enforced sandbox that limits what it can touch" and that "By default, the agent runs with network access turned off," controls on a local session that leave credential handling undescribed (OpenAI, 2026).

What does a vendor compromise yield when the root is elsewhere?

Take the record from the first section: a repository settings page that lists an agent's deployment grant. With a vendor root the signing key sits in the vendor's service, so an attacker who compromises it can mint a grant for the same repository with a wider environment and a longer expiry, and the settings page renders it as legitimate. The attacker gains the session and, with it, the ability to create authority.

In the developer-rooted design the page is the same and the outcome is not. The attacker finds a session and a rendered grant, and the grant carries a signature that verifies against a public key pinned in the repository's policy. Without the developer's private key, which never entered the vendor, the attacker cannot sign a new scope. The existing grant can be replayed until it expires, and the page's token is bound to the approved destination.

Willison's design patterns "constrain the actions of agents to explicitly prevent them from solving arbitrary tasks," which reduces what a compromised agent can do with whatever authority it holds (Willison, 2025). The material a compromise does find is still valuable: GitGuardian counted "28,649,024 new secrets exposed in public GitHub commits across 2025," with commits co-authored by an AI coding agent leaking at roughly double the baseline (How Do You Let an AI Agent Manage API Keys Without Reading Them?). A root outside the vendor reduces what that population yields to an attacker inside it.

How does a signed grant change who can be held to an action?

A dialog is not a grant. OWASP's attack page records that HITL dialog forging "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations," so a click on a dialog is not by itself evidence of what was approved (OWASP Foundation, n.d.). The person may have approved a payment to one account while the dialog showed another, and nothing in the click record would show the difference.

A signed grant fixes the content of the approval rather than the appearance of it. The signature covers the destination, the scope, the expiry and the approver's name, so a dialog that changes what the person sees changes what they sign, and the signature no longer matches the action the agent attempts. Verification needs only the public key, which the organization can pin. The same summary of FINRA's report notes that agent chains "may be difficult to reconstruct, complicating auditability," which makes a signed record more useful than a log of clicks (Debevoise & Plimpton, 2026).

The actions that need this cannot be undone. In a walkthrough of an EC2 GPU launch, "Five of those steps commit the account to something you cannot take back, and those five stop," and the stop is only meaningful when the approval is bound to the exact action rather than to a general permission to proceed (How to Use AI Agents to Launch an EC2 GPU Instance, 2026). A grant names a person, a scope and a period, and the signature shows the person made that statement and no wider one, a claim an auditor can test without the vendor's systems.

What does a governed environment change?

A governed environment is a control class that sits between the rendered page and the model. Values chosen by policy are replaced with consistent tokens before any model reads the screen. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, and every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

It changes where authority can be exercised. The environment enforces a scope and cannot widen one, because the grant it enforces is signed with a key the environment does not hold. An attacker who compromises the environment finds tokens, sessions and grants that were already signed, and cannot mint a grant for a wider scope. A forged approval dialog cannot manufacture a signature either, because the signature covers the action's content rather than the dialog that described it.

The scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP. What it adds is narrower: the model holds placeholders, real values appear only where an approved action sends them, and the record names who approved what. Environmental injection against generalist web agents reached an attack success rate of up to 70 percent in stealing personal information Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?.

A vendor compromise then has a ceiling: it can expose what the environment held and stop work until the developer revokes the grant, and it cannot create authority the developer never signed.

Methodology and limitations

The page rests on five vendor documentation pages (Teleport, Cursor, 1Password and Browserbase, Composio and OpenAI), one law firm summary of a regulator's report, one industry breach report, one practitioner analysis and one community standards page, plus the RedactSure research pages cited for the control class. Vendor and research facts are given in the wording recorded for each page, and quotations are the pages' own. The OWASP page is cited for the attack it records, and the practitioner analysis for the patterns it proposes rather than for a measured result. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page.

RedactSure did not test any of these products hands-on. Where the page says a behavior is not described in the pages reviewed, that means the recorded facts for that page do not contain it, not that the vendor's product does not do it. Vendor features change, and the page carries its date, so a reader should confirm a specific control with the vendor before relying on it. RedactSure statements describe current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a repository settings page with an agent's deployment grant, not any organization's system.

Determinations about a specific deployment belong to the organization's counsel, its assessors and its own security and compliance officers. This page describes a design question and the evidence recorded around it; it does not decide whether a given agent, vendor or grant satisfies a legal, regulatory or contractual standard. A reader should take it as a starting point for that review, not as its conclusion.

What the record shows

The record supports a narrow conclusion. The pages reviewed document identity, custody and approval, and none documents a signing key held by the developer, so the answer rests on the design argument rather than on a vendor's specification: a party that can mint a grant is the authority, and a breach of that party is a breach of the authority. A developer-held root does not make a vendor compromise harmless. It changes what the compromise yields, from new authority to existing sessions and grants that were already signed, and it keeps the party who answers for the grant inside the consent chain. Before signing with a vendor, a buyer can test this on one agent and one task: ask the vendor for the sentence that says who can sign a new grant for that task, then compare it with who would answer for the grant if the scope were exceeded.

Frequently asked questions

Why should the developer's private key be the root of authority for agents?

Because the developer is the party the credential owner consented to and the party who can be held to the scope of a grant. A key held by the vendor makes the vendor the authority, and a vendor breach becomes a breach of the authority rather than of one credential. The root belongs where the accountability already sits. The test is whether the vendor can create authority without the developer's signature, and the answer should appear in writing.

Does a developer-held key mean the vendor never holds a credential?

No. The vendor still runs the environment, holds sessions and enforces the scope. What changes is the ability to create authority: the vendor can use a grant that was signed and cannot sign a wider one. That limits what a vendor compromise yields without making the vendor irrelevant. The distinction matters in an incident, when the question is whether the attacker can issue new permissions or only replay old ones. Ask which of the two the vendor's architecture allows.

What happens to an agent's grants if the vendor is breached?

Existing grants survive until they expire or the developer revokes them, and the attacker holds whatever sessions and ciphertext the vendor stored. A new grant requires the developer's signature, so the attacker cannot widen scope or extend expiry without it. Recovery is a revocation, not a replacement key, because the root was never in the vendor's systems. A vendor that cannot describe this sequence has not separated the root from its own infrastructure.

How can a developer prove who approved an agent's action?

The approval should be a signature over the content of the action: the destination, the scope and the expiry, with the approver's name attached. A log line that records a click proves that a dialog was shown, not what it said. Verification needs only the public key, which the organization can pin the way it pins any other signing key. Ask to see one verification run against a scope the vendor has never seen.

Is a human approval dialog enough authority for an agent action?

Not on its own. A rendering can change before the person sees it, and OWASP's page on HITL dialog forging records that the attack "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations" (OWASP Foundation, n.d.). Binding the approval to the action's content, and signing it, is what makes the person's decision checkable afterwards. A click is evidence that a dialog appeared, not evidence of what the person agreed to.

What should a team ask before letting an agent act under a developer key?

Ask who can sign a new grant, where the private key is stored, how a signature is verified, and what a vendor compromise would yield. Ask which actions require a fresh approval and which record shows what the model saw before it proposed them. Ask how revocation works while a grant is in flight. A vendor that answers with a document is easier to test than one that answers with an architecture diagram.

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 Puts the Root of Authority in the Developer's Key

The key that signs a grant decides who can create one, and the approaches above leave identity, custody or approval, and with it the authority, with the vendor.

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

Before, the page gave the model the full grant and a copyable token, and a compromised vendor could mint a wider one. Inside it the page renders GRANT_014 and DEPLOY_002, TrustGate verifies the developer's signature on the grant, and the signing key stays with the developer. The developer approved the scope and deployment.

RedactSure is deploying now with enterprise and government customers. Verizon's 2026 report records that breaches "now start with software vulnerabilities."

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

See it on your own workflow

Authority that starts with your private key is authority a vendor cannot widen without your signature. Bring a deployment task and see, with test values, the grant verified against your signature. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.