Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is a Root of Trust for AI Agents?

A root of trust is the key from which every grant an agent holds derives its authority, so whoever holds it can authorize anything, and that is why it belongs with the person who delegated the work, not with the agent. Ask which key signs each grant, where its private half lives, and who could use a copy.

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

Security reviewers who sign off on an agent system need to know what anchors the authority the agent presents. A root of trust is the anchor at the bottom of a chain of signatures. A laptop checks its boot sequence against one, a certificate hierarchy signs its intermediates with one, and an agent system signs the grants an agent presents with one. The term also gets used for weaker things, which is where security reviews go wrong: a permission, a sandbox, a credential store and an identity provider each answer a different question, and none of them answers who can create authority in the first place. Putting the signing key back at the base of the chain separates those four, and the running example is one record type, a grant chain that resolves to a single key on a repository settings page. The vendor documentation closest to the idea, the regulator guidance on delegated action, and the research on how often keys end up where they should not be lead to one answer: a root of trust is a custody question before it is a cryptography question. This means the questions that decide a review are who holds the private half and what a copy of it would authorize, and a reviewer should ask both of every grant before approving the system.

Key findings

  • Teleport's framework states that agents need "a verifiable, cryptographic identity tied to where they're running, not a shared API key," which puts authority in a key pair instead of a string that can be copied out of a settings page (Teleport, 2026).
  • Cognition's Devin guide states that "In the browser, Devin types the value directly," so the credential is used on the page the agent is directing rather than in its shell (Cognition, 2026).
  • Truffle Security reported that "11,908 Live Secrets were detected using TruffleHog in 400TB of web data," which is the population a root key has to survive (Truffle Security, 2025).
  • Exposure is a separate control from permission: least privilege governs the actions and credentials an agent may use, and it does not govern the content of the screen the agent reads, so an agent can satisfy it in full and still hold every record it was shown (What Is Least Exposure?).
  • Permission and exposure are two layers, and a review that checks one of them has checked half the run. A tether describes the authority an agent carries, not the capability it has, so an agent that stays inside its authority can still read every value its supervisor could have seen on the same page (What Is a Tethered Agent?).

What does a root of trust control that a permission does not?

A permission answers a question about one subject: may this agent read this repository, call this endpoint or change this setting. A root of trust answers the question underneath it: who can create, widen or transfer that permission. The first is a statement, the second is the key that signs the statements, and every grant in a system is valid only because a signature from that key verifies against it.

The chain has three parts. The root key signs a grant. The grant names a subject, a scope, an expiry and often a single use. A verifier checks the signature against the root's public half before the action runs. The agent presents the grant and never the root, which is the property that makes delegation work: authority travels, and the means of creating authority stays where it was.

That is why the term is used loosely. A sandbox bounds where code runs, and gVisor's security model says the boundary is not the whole answer: "A sandbox is not a substitute for a secure architecture" (gVisor, 2026). A credential store holds a value; if it hands the value to the agent at the moment of use, the agent becomes the holder.

The scope here is the rendered page. A governed browser environment covers what an agent reads and does on a rendered page, a console, a dashboard or a settings page, and it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A root key kept for a company's own signing infrastructure sits in the last group, as does the shell an agent uses to call an API. Content the agent retrieves is the usual delivery route for an injected command, as What Is Indirect Prompt Injection and How Does It Reach AI Agents? sets out.

Who should hold the root of trust when an agent acts for a person?

Three parties can hold it: the agent's runtime, the vendor's platform, or the person who delegated the work. The first is the worst, because everything that reaches the model reaches the key, and an injected instruction does not need to forge a grant if the agent can sign one (What Is the Lethal Trifecta for AI Agents?).

A vendor platform is a common default. Composio documents that "Each user can have multiple, even for the same toolkit (e.g. work and personal Gmail)," so one connected account is not one identity (Composio, 2026). The same page states that "Composio refreshes access tokens automatically before they expire, so connections stay ACTIVE," which leaves the platform holding the material that renews every connection it stores (Composio, 2026).

Custody with the delegating person looks different. The person holds the key, signs a grant for one task, and hands the agent the grant. The agent can act inside that grant and cannot mint another. That is the tether idea, and the link it describes is authority rather than capability: a tethered agent goes where its supervisor could go and cannot slip the line back to the person who set it up, as What Is a Tethered Agent? describes.

The guidance for cloud root accounts advises against creating access keys for the root user, which removes the simplest way an agent could be handed durable top-level power (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). A root that is never copied into a runtime is a root that cannot leak out of one.

What do the vendors themselves say?

Five vendor pages describe one segment of the chain each, and each is specific about what its product decides and quiet about the key behind it.

Teleport's framework promises "Comprehensive audit trails and behavior analysis for agent actions across infrastructure," while the same page marks most of its listed capabilities "In-progress" or "Not started" and gives no certificate lifetime (Teleport, 2026). An audit trail records what happened; it does not say who could have signed for it.

Cognition's guide scopes credentials to an organization, a person, a repository or a session, and states that "For shell commands, it binds secrets as environment variables whenever needed" (Cognition, 2026). It adds that "All secrets are encrypted at rest," and whether the model sees the value is not described in the pages reviewed (Cognition, 2026).

NVIDIA's OpenShell page puts policy outside the component that runs the agent, with a sandbox that "shares the boundary with the untrusted agent, so it never makes policy decisions," and a Gateway that "Checks who you are and remembers everything about your sandboxes" (NVIDIA, 2026). It does not explain how a policy is written, and the check it describes is of identity, not of a signature over a grant. gVisor's model states that "No system call is passed through directly to the host," and that it "relies on the host operating system and the platform for defense against hardware-based attacks" (gVisor, 2026). Both statements are about isolation, and neither describes a key that authorizes an action.

Vendor, per its documentation What the page documents What a buyer should verify
Teleport A cryptographic identity per agent runtime, and audit trails the page marks mostly in progress Certificate lifetime and which of the listed capabilities are available now
Cognition Credential scopes down to a single session, with the browser path typing the value directly Whether the model receives the value, which the page does not say
Composio Repeatable connected accounts per toolkit, with automatic token refresh Who can authorize a connection, and what happens to calls in flight when one expires
NVIDIA A Gateway that checks identity, and a sandbox that never makes policy decisions How a policy is written, which the page does not explain
gVisor System calls mediated rather than passed to the host, with reliance on the host for hardware attacks What holds a key inside the sandbox, which the page does not address

How does a grant chain resolve back to one key?

The record type is a repository's deploy-key settings page, opened by an agent asked to rotate a key. The page lists the existing keys with their fingerprints, the scope each carries and the date it was added, and an access panel above the list names the key that signed the grants for the current session.

The chain on that page has three links. The root key, held by the person who delegated the task, signs a grant that names one repository, one operation and one run. The agent's session presents that grant. The host verifies the signature against the root's public half, checks the expiry and the scope, and writes the action to its own log. Nothing in that flow requires the private half to leave the client, and nothing the page renders exposes it.

Revocation is the reason to keep the chain short. A grant can be revoked at the end of the run without touching the root, and a root can be rotated without reissuing every grant if the grants are short-lived. A chain with the root inside the agent has neither property: the only way to stop the agent is to destroy the thing every other grant depends on.

The steps that commit an account are the ones the chain has to gate. Launching an EC2 GPU instance is a worked example: five of those steps commit the account to something you cannot take back, and those five stop, as How to Use AI Agents to Launch an EC2 GPU Instance walks through. Keys that end up in a transcript are the ordinary case, which is why public commit counts run to the tens of millions for a single year, a figure set out in How Do You Let an AI Agent Manage API Keys Without Reading Them?.

What happens when a root key is exposed?

Every grant verifies against that key, so a holder can mint a grant for any subject, any scope and any expiry, and every verifier downstream will accept it. Expiry does not help, because the holder sets the expiry. Least privilege does not help, because the holder writes the scope.

Truffle Security also reported that "2.76 Million Web Pages contained live secrets," so the problem is a property of the web and not of one repository (Truffle Security, 2025). OWASP's non-human identity list calls NHI2 Secret Leakage the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores" (OWASP, 2025). The same list names overprivileged identities as NHI5, the second failure a leaked root makes worse (OWASP, 2025).

A forged grant looks like a valid one because it is valid; the log records the grant, not the hand that created it. Debevoise & Plimpton's summary of FINRA's 2026 report warns that "Agents may act without human validation and may take actions that exceed the user's actual or intended scope or authority," and adds that agent chains "may be difficult to reconstruct, complicating auditability" (Debevoise & Plimpton, 2026).

Datadog's DevSecOps report found that "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions," a long-lived credential where a short-lived role would do (Datadog, 2025).

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders such as GRANT_014 or KEY_003. 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.

For this page's question the control class changes two things. The first is what a leaked transcript contains. If the model reads a settings page as tokens, the transcript holds GRANT_014 and KEY_003, which are worthless outside the environment that issued them, and the root key is never in the run to be copied out. The second is the record. A permission model can say what the agent was allowed to do; a governed environment can say what it saw, what it did and who approved it, screen by screen.

The layer that is easy to confuse with this one is the root itself. A root key decides who can create authority; a governed environment decides what the model is shown while that authority is used. A system with only the root has an agent that can act and a page that hands it the values it acts on. A system with only the tokens has placeholders whose grants nobody can trace back to a signer.

A root key that stays with the delegating person is only usable if the work can proceed without it, and tokens plus an approval are how the work proceeds: the environment holds no root, the person approves the steps that matter, and the record shows which grant was used for each one.

Methodology and limitations

This page rests on vendor documentation from Teleport, Cognition, Composio, NVIDIA and gVisor, on standards and guidance from OWASP and a law firm summary of a FINRA report, on vendor research from Truffle Security and Datadog, and on 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. Quoted facts are cited to the page that states them, and the FINRA wording is Debevoise & Plimpton's summary of the report, attributed to the summary rather than to the regulator's own text. No source outside those pages is used.

RedactSure did not test any of the named products hands-on. "Not described in the pages reviewed" means the recorded page does not state the point; it does not mean the product lacks the capability. Vendor features change, and this page carries its date, so a release after that date is unreviewed until the same pages are read again. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a grant chain that resolves to one key on a repository settings page, and not an organization. It is described at that level so a reader can reproduce it on their own system.

Determinations about whether a particular delegation, key custody arrangement or audit record meets a contractual, regulatory or industry requirement belong to counsel, assessors and the organization's own security and compliance officers. A written determination should name the record and the approver it relied on. Nothing here replaces a test of the organization's own agent, its grants and its custody against the record type above.

What the record shows

For anyone approving an agent deployment, the pages read together describe a chain that is easy to draw and hard to secure. A vendor can issue an identity tied to where the agent runs, a gateway can check that identity, a sandbox can mediate system calls, and a store can encrypt what it holds; none of those pages says who can sign a grant for the agent, and a leaked key makes every other control moot. Custody is the question that decides the answer: a root held by the runtime is one injection away from being used, a root held by a platform is one vendor decision away, and a root held by the person who delegated the work is the only arrangement in which the agent can act without being able to authorize. RedactSure's environment is built for that last arrangement. To test a deployment against this, trace one grant from one agent to the key that signed it, then ask who holds that key and what a copy of it would authorize.

Frequently asked questions

What is a root of trust for an AI agent?

It is the key that signs the grants an agent presents, and the anchor every verifier in the chain checks against. The agent holds a grant that names a scope and an expiry; the root holds the ability to create such grants. That separation is what lets an agent act with delegated authority without carrying the means to widen it. When the term is used for a sandbox, a permission or a credential store, the speaker usually means a different control.

Is a root of trust the same thing as an API key?

No. An API key is a credential a service accepts, and it is usually both the identifier and the credential. A root key is not presented to a service at all; it signs grants that are presented instead. A leaked API key gives the holder the access that key carries. A leaked root key gives the holder the ability to create any access the system will accept, which is why custody matters more for the root than for any single key.

Who should hold the root key for a team of agents?

The person or group accountable for the work the agents do, on a device or service that person controls, with the agent holding only signed grants. Holding it in the agent's runtime makes every prompt injection a possible signing event. Holding it at a vendor makes the vendor the authority for the customer's actions. The test is simple: who can authorize a new grant without asking anyone else, and does that match who is accountable for the work? That custody answer is the one a security review can test.

How can an agent act without the root key?

It presents a grant the root signed. The grant names the subject, the resource, the operation and an expiry, and often a single use or a maximum count. The verifier checks the signature with the root's public half, which can be published; only the private half must stay hidden. Certificate chains have worked this way for decades, and it is why a short-lived grant can be handed to an agent that should not be trusted with anything longer.

What happens if the root key is exposed?

Every grant verifies against it, so an exposed root lets an attacker mint valid grants for any scope. Expiry and least privilege do not contain the damage, because the attacker chooses both. The remedy is rotation and reissue, which is expensive in proportion to how many grants and integrations depend on the key. The reason to keep the root out of automated paths is that a forged grant is indistinguishable from a valid one until the signer is checked.

Does a sandbox remove the need for a root of trust?

No. A sandbox bounds what an agent's code can reach, and gVisor's own model says a sandbox is not a substitute for a secure architecture. Isolation and authority are different properties: one limits where the work runs, the other decides who can authorize it. A sandboxed agent with a signing key in its environment can still mint a grant the rest of the system accepts. The two controls are complements, not alternatives, and a vendor page rarely makes both claims on the same page.

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 Keeps a Root Key Out of the Agent's Run

The vendor pages reviewed describe identity, isolation and storage without saying who signs for the agent, and a key the agent reads is one an injection can use.

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

Before, an agent rotating a deploy key reads the key list, the fingerprint of the signing key and the private half the page shows once. Inside the governed environment, the page renders GRANT_014 and KEY_003, and the real key reaches the repository only on a named approval.

RedactSure is deploying now with enterprise and government customers. Truffle Security counted "11,908 Live Secrets" in 400TB of web data.

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

See it on your own workflow

A root key belongs outside the agent's run entirely, including while a deploy key is being rotated. Bring a key rotation your team performs and see, with test values, what the model reads on the key list. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.