Most enterprise automation projects don't stall on the browser part—they stall in the security review. Someone asks where the portal password lives, and the honest answer is "in an environment variable the automation script reads," or worse, "in the script." That's the moment a compliance team stops the rollout, and it's a fair objection: a service account credential sitting in plaintext next to business logic is exactly the kind of thing a SOC 2 or access-control audit is designed to catch.
Where the Review Actually Stops You
Authenticated enterprise portals—payroll systems, insurance carrier consoles, ERP admin screens—almost never separate "logging in" from "doing the work." A script that automates the portal ends up holding the same credential a human employee uses, with none of the separation of duties a security team expects: no independent record of which identity performed which run, no way to revoke access to the automation without rotating a password shared elsewhere, and no answer for what happens when that script's logs (or its error messages) end up printing the session cookie.
None of that is a browser automation problem specifically—it's what happens whenever credential handling isn't designed in from the start.
Separating What Logs In From What Automates
Anchor's identities model exists for exactly this separation. An identity represents one account on one application—its credentials, its saved browser profile, and which login flow it uses—and it's created once, independently of any automation code:
const identity = await anchorClient.identities.create({
source: 'https://payroll.acme-vendor.com',
name: 'Payroll Admin - Finance Ops',
credentials: [{
type: 'username_password',
username: process.env.PAYROLL_USER,
password: process.env.PAYROLL_PASS,
}],
});
const session = await anchorClient.sessions.create({
identities: [{ id: identity.id }],
session: {
recording: { active: true },
tags: ['payroll-run', 'finance-ops'],
},
});
// Session starts already signed in. The automation script
// never sees the username, password, or session cookie.The automation only ever references identity.id. The raw credential lives in one place, attached to one named identity, and a security review has a single answer to "who can use this login" instead of however many scripts happen to reference an environment variable.
Failing Closed Instead of Failing Quiet
The harder compliance question is what happens when access should stop working—a password rotation, an offboarded vendor contact, an expired MFA enrollment. Anchor's identities don't paper over that: if the saved browser profile has expired and no valid credential is available to re-authenticate, the session doesn't attempt to guess its way back in. It requires either the stored credentials to run the login flow again or a manual re-authenticate token issued through POST /v1/identities/{identityId}/re-authenticate-token. A revoked account produces a failed, auditable session instead of a silent automatic re-login that a compliance reconstruction would never catch.
Making Access Reviewable, Not Just Functional
Identity metadata and session tags turn "it works" into something an access review can actually query. Tagging an identity with an owner and department, and tagging each session with the workflow it belongs to, means a compliance team can later answer "which identities touch the payroll portal" or "show me every session that ran under the finance-ops identity last quarter" without reconstructing it from script history:
const identity = await anchorClient.identities.create({
source: 'https://payroll.acme-vendor.com',
name: 'Payroll Admin - Finance Ops',
metadata: { owner: 'finance-ops', department: 'Finance', reviewed: '2026-Q3' },
credentials: [{ type: 'username_password', username: user, password: pass }],
});Combined with session.recording.active—on by default—every run against that identity has both a queryable record of who ran it and a visual record of what happened on screen, which is the pairing most access reviews actually ask for.
Compliance as a Design Input, Not a Blocker
None of this is about getting past a portal's defenses. It's authenticated access, using an account the team already has standing rights to, with the credential handling a security review expects to see: one identity, one owner, one auditable trail, and a system that fails closed when access should have already been cut off.
If your team is stuck between "the portal has no API" and "the security review won't approve a hardcoded password," that's the gap Anchor's identities are built to close. Get an API key and try attaching an identity to the next authenticated portal you need to automate.
