Last updated: July 2026.

The request usually arrives as a line item on an evidence list: describe how automated workflows authenticate to third-party applications; provide evidence that multi-factor authentication is enforced on these accounts; identify who has access to the credentials. The workflow in question has been running for a year. It logs in the way the engineer who built it got it working, and nobody has written that down, because until now nobody asked.

This page covers what the auditor is mapping your answer to, why the improvised answers tend to become findings, and how to write a control description that states the authentication story plainly, with evidence behind each sentence.

What the auditor is mapping your answer to

In a SOC 2 examination, automated logins land under the logical-access criteria, the CC6 series of the Trust Services Criteria: how credentials are issued, protected, restricted, and monitored. NIST SP 800-63B supplies the vocabulary for the factors themselves: a memorized secret (the password) and a one-time password from an authenticator are distinct authenticator types, and a control that stores both in the same place has quietly merged them.

Behind the framework language, the auditor is asking three concrete questions:

Who holds the credentials these workflows use, and where do the credentials live?
Is MFA enforced on these accounts, and if it is not, why not?
What evidence exists of what the automation actually did in any given session?

Whether a control is suitably designed is the auditor's judgment. What you control is the facts available for the description.

Why the improvised answers become findings

Teams that automated a browser workflow before anyone asked these questions usually have one of three answers on hand, and each one tends to convert an authentication question into a written finding.

The service account has an MFA exemption. The exemption is what gets written up. Conditional-access exclusion groups are among the first things an access review checks, and "this account is excluded so the bot can log in" is a remediation item with a due date.
The TOTP seed lives in the secret store next to the password. MFA stays technically enabled while both factors sit in one custody point, and the auditor's follow-up about who can read that secret store has an uncomfortable answer.
The bot borrows a person's account. Now the audit trail attributes the automation's actions to a human, and the evidence question ("show me what the automation did") has no clean answer at all.

Each pattern keeps the workflow alive. Each one also puts the team in the position of explaining a weakened control instead of describing a sound one.

Authentication the description can state plainly

Managed browser infrastructure changes what the control description gets to say, because credential custody and MFA completion become properties of the platform rather than improvisations around it. Anchor Browser is browser infrastructure in this category, built for computer-use agents and authenticated automation. The load-bearing facts, each at a published source:

Credentials are held once, in an identity layer. An identity stores a credential once, and Anchor re-authenticates automatically when a session needs it, so sessions start already signed in. Alternatively, the 1Password integration resolves credentials, including one-time codes, from your own vault at runtime; Anchor stores the service-account token, and the secret values stay in the vault. Per Anchor's security documentation, customers are never required to store credentials on the platform at all.
MFA stays enforced, with the challenge completed in-flow. Identities support authenticator-type (TOTP) credentials (credential types). Email one-time passcodes route to a dedicated mailbox per identity and are consumed automatically during identity creation, re-authentication, and agent sessions. For codes that must come from your own systems mid-run, event coordination pauses the flow, receives the code from your backend, and resumes. The account keeps MFA on, and the description contains no exemptions to explain.
The AI model never sees the credential. Secret values resolve only at the moment of typing, are processed in memory and never persisted, are excluded from all logs and telemetry, and can be scoped to specific domains.
Each run is isolated and recorded. Every session executes in a dedicated virtual machine that is permanently terminated and erased at session end (security documentation), and sessions record to MP4 by default, retrievable per session through the API and the session-history dashboard.

A control description you can adapt

A starting point for the system description or the control narrative, with every clause traceable to the sources above. It describes your configuration, so keep it true: MFA stays enforced on the accounts, and no exclusion groups get created for the automation.

Automated browser workflows authenticate to third-party SaaS applications through a managed browser platform (Anchor Browser). Application credentials are stored once on a per-application identity in the platform's identity layer [or: are resolved at runtime from the organization's 1Password vault via a service-account integration] and are injected only at the moment of typing. Plaintext credential values are not visible to the AI agent driving the browser and are excluded from session logs and telemetry. Multi-factor authentication remains enforced on the application accounts: TOTP and email one-time-passcode challenges are completed within the platform's managed authentication flow, and no MFA exemptions or conditional-access exclusions are configured for the automation. Each session executes in a dedicated virtual machine that is permanently terminated and erased at session end, and sessions record to video by default, providing a per-run record of the actions taken.

The evidence pack: which artifact answers which question

Audit question	Artifact
Who holds the credentials?	The identity configuration (or the 1Password vault and its access policy), plus the published secret values and 1Password documentation stating that plaintext values are never exposed to the agent, logs, or responses.
Is MFA enforced on this account?	Your identity provider or application tenant's MFA policy, unchanged, plus the identity's credential configuration showing TOTP or email-OTP challenges completed in the managed flow.
What did the automation do in this session?	The session's MP4 recording, on by default and retrievable through the API and the session-history dashboard.
What is the vendor's own posture?	Anchor's trust center: the SOC 2 Type 1 and Type 2 reports, ISO 27001 certification, a security whitepaper, the data processing agreement, a subprocessors list, and the security policies, with access requestable for private items.
What if recording itself violates our data-handling policy?	Zero-data-retention mode disables video and log recording entirely; note the stated tradeoff that recordings and logs are then unavailable for troubleshooting, so the evidence approach for ZDR workloads should be agreed with the auditor up front.

Frequently asked questions

How do I tell an auditor how our bots log in? In the vocabulary of custody and factors: credentials are held once in a managed identity layer (or resolved from your own vault at runtime), injected at typing time, invisible to the AI model, and excluded from logs; MFA challenges are completed inside the managed flow, so the accounts keep MFA enforced. The control description above is an adaptable starting point.

Does using an automation platform mean MFA is turned off for those accounts? No. Anchor identities complete authenticator (TOTP) and email one-time-passcode challenges inside the managed authentication flow (authenticated applications, email OTP), so the tenant policy stays enforced with no exclusion group.

What audit evidence exists for automated SaaS logins? Per-session MP4 recordings, on by default and retrievable by session through the API and dashboard, alongside the identity configuration and the published credential-handling documentation.

Can the auditor rely on Anchor's own audits? Anchor publishes its compliance set on its trust center, including SOC 2 Type 1 and Type 2 reports available on request; your auditor can evaluate the reports' scope directly as part of vendor review. The pricing page maps compliance terms to plans, with the BAA and DPA at the Enterprise tier.

Who can see the password while the automation types it? Nobody in the loop. Secret values resolve at the moment of typing, stay in memory, and are excluded from all logs and telemetry; with the 1Password integration, values are never exposed to the agent, the logs, or API responses.