# Sensitive data and handoffs

Understand how humans, Agents and the Runtime handle sensitive configuration, including trusted entry, encryption and the limits of hidden values.

Last updated: 2026-10-18

An Agent can prepare sensitive setup while you supply the sensitive value or approve account access
in a browser. Typenode then makes the resulting configuration available for authorized Workflow
use. These are separate stages with different access boundaries.

## What the Agent prepares and you complete

| Setup | The Agent prepares | You complete |
| --- | --- | --- |
| [Manual Secret](/configuration/secrets#supplying-a-sensitive-value) | Name, Environment and intended change | Sensitive value entry in Typenode |
| [Credential](/configuration/credentials#authorizing-an-account) | Account authorization request, including the app, Environment, name and OAuth scopes | Browser authorization with the service |
| [Custom OAuth app](/configuration/oauth-apps#a-custom-apps-sensitive-details) | Registration configuration | Sensitive registration details in Typenode |

Enter sensitive values through these interfaces rather than in chat. Secret setup tools carry the
prepared configuration without a Secret value argument. A sensitive value pasted into chat has
already been given to that AI app, regardless of how Typenode later stores it.

Before entering a Secret or an OAuth app's client secret, check the browser's address. Typenode's
production app is at [app.typenode.ai](https://app.typenode.ai). Account authorization also takes you
to the outside service's own sign-in and consent pages, where you review the account and access.

## What a handoff link authorizes

A handoff request describes a particular prepared action. Its link alone is not permission to make
that change. Completion requires the appropriate browser continuation, a signed-in Member in the
matching Workspace, and current authority for the action. The prepared request is checked when it
is completed; expired or conflicting requests cannot simply be applied as new instructions.

Preparing the handoff is not successful setup. After you finish, the Agent checks the resulting
resource before treating it as ready for a Workflow.

| Setup | What to check after completion |
| --- | --- |
| Manual Secret | The completed change and saved Secret metadata match the requested name and Environment; readback does not reveal or verify the value |
| Credential | The saved Environment, Secret name, connected account and recorded OAuth scopes match the intended authorization |
| Custom OAuth app | The saved registration matches the intended service and client ID; saving an app does not connect an account |

A Credential's connected status alone does not establish the intended account, and recorded scopes
do not prove the service's current consent. Review the account and access during authorization;
[Credentials](/configuration/credentials#authorizing-an-account) explains the checks.

An Agent's access inside Typenode is limited by its approved access and the Member's current
authority. [Agent access](/agents/access) explains that relationship.

## What management tools return

[Variables](/configuration/variables) are readable configuration. Their management responses can include values.

Secret management responses return metadata, such as the name and whether a Credential maintains
it, without returning the Secret value. This lets an Agent inspect configuration status without
asking you to reveal the token in chat.

Being able to manage or use sensitive configuration is still consequential access. Review which
actions a Member and their Agent can perform, including changing Workflows that use that
configuration.

## Encryption and runtime access

Secret values and sensitive OAuth material are encrypted in storage using AES-256-GCM. Encryption
binds stored material to its intended context and record.

This protects stored material while allowing authorized Typenode components to decrypt it when
needed. For example, token refresh needs access to OAuth material, and running a Workflow needs
access to the token used for an API call. This is server-decryptable storage encryption; it does
not establish end-to-end encryption or a claim that Typenode cannot access the material.

## Secret exposure through Workflows

Hidden configuration responses are one protection boundary. They do not guarantee that a Workflow
cannot expose sensitive data through its behavior. A Workflow can send data to outside services or
return output that an Agent later reads.

Someone who can change and run a Workflow using a Secret may be able to expose it through that
Workflow's outgoing requests or returned data. This includes an Agent with those capabilities.

Review how a Workflow uses sensitive values, which service receives them, and what its outputs
contain. Keep account authorization limited to the access the task needs. Use separate
[Environments](/configuration/environments) when testing should use different accounts or values.

## Removing access

[Disconnecting an Agent](/agents/access#disconnecting) stops that connection's access to Typenode.
It does not cancel Runs already accepted, remove Credentials or revoke keys at outside services.

[Replacing a manual Secret](/configuration/secrets#changing-a-secret) changes the value stored in Typenode. Rotate or revoke the original key
at its issuing service when that access needs to end.

Deleting a Credential removes its token material from Typenode and attempts service-side token
revocation. To ensure authorization is withdrawn at the service itself, remove the app's access
there as well. See [Credential deletion](/configuration/credentials#deleting-a-credential).

For broader data handling information, read Typenode's
[privacy policy](https://typenode.ai/legal/privacy-policy).