Steel's Credentials API stores login values separately from the agent and injects matching credentials into a browser session. The agent can navigate to a login page without receiving the raw username, password, or TOTP secret.
The Credentials API is currently documented as beta. Treat its interface and behavior as versioned infrastructure, and review the current documentation before each production rollout.
Store credentials for an origin
await client.credentials.create({
origin: "https://app.example.com",
namespace: "production-operator",
value: {
username: process.env.APP_USERNAME,
password: process.env.APP_PASSWORD,
},
});
Use namespaces to separate credentials for the same origin. The namespace used during session creation must match the stored credential.
Enable injection for a session
const session = await client.sessions.create({
namespace: "production-operator",
credentials: {
autoSubmit: false,
blurFields: true,
exactOrigin: true,
},
});
Steel's documented defaults enable autoSubmit, blurFields, and exactOrigin when credentials: {} is supplied. Set the fields explicitly when the security policy depends on them.
Disabling automatic submission creates a useful approval boundary. The service can fill the form while your application verifies the origin and asks an operator or policy engine whether submission is allowed.
Enforce the boundary in your application
Credential injection reduces secret exposure, but it does not replace authorization. Your application should still:
- authorize which actor may use each namespace;
- restrict sessions to expected origins;
- avoid logging credential request bodies;
- protect live viewer access;
- revoke stored credentials when account access changes;
- record which task requested credential use.
Treat screenshots and page content as potentially sensitive after login. Blurring input fields protects the injected values; it does not make the rest of the authenticated page public.
Combine credentials with profiles carefully
Credentials establish or restore authentication. Profiles persist browser state such as cookies and local storage.
A common flow is:
- create a session with a credential namespace and
persistProfile: true; - verify that login succeeded;
- release the session so the profile is saved;
- use the profile for later runs;
- fall back to credential injection when the saved login expires.
This reduces repeated logins without turning one browser profile into a shared identity.
Use the Credentials API overview to create a test credential under a non-production namespace before enabling injection for real accounts.