How we architected browser automation to be as secure as an API

TL;DR

"Browser automation" makes CISOs flinch. We built one that satisfies them.

Security engineers imagine brittle scripts, hard-coded credentials, no audit logs. The alternative - manual provisioning - is worse: spreadsheets, human error, zombie accounts.

We built infrastructure, not a bot:

• Proxy, not database - we execute actions, never store your data
• Isolated containers - every run in its own ephemeral environment
• AES-256 credentials - injected at runtime, never visible to humans
• Full video audit - every HITL intervention recorded and timestamped

SOC 2 Type II certified.

Core principle: Proxy, not database

When security engineers hear the words "browser automation," they usually flinch.

They imagine brittle scripts running on a laptop, credentials hard-coded in plain text, and a complete lack of audit logs. They are right to be skeptical. Traditional RPA and homegrown scripts are a governance nightmare.

But the alternative - manual provisioning - is worse. Manual work means spreadsheets, human error, and "zombie" accounts that stay active months after an employee leaves.

We built Stitchflow to solve the SCIM Tax and the disconnected app problem. We analyzed 721 SaaS apps: 42% lock SCIM behind enterprise pricing, and another 57% have no SCIM at any price. That's 98.8% of apps where manual provisioning is the default. To solve this at scale, we had to build a browser automation engine that satisfied the strictest CISOs in the world. We did not build a "bot." We built a managed infrastructure layer.

Most third-party tools want to suck your data into their system to analyze it. We don't.

We operate on a strict "Proxy, Not Database" philosophy. Stitchflow performs actions inside your app UI, but we do not store or process user PII beyond what is absolutely required for that specific execution.

• We are a pass-through: We take the signal from Okta or Entra and execute it in Adobe or Figma.
• No retention: We do not replicate, cache, or index your SaaS data.
• Zero Trust: We treat every run as a discrete, ephemeral event.

Isolation by default

A risk in automation is cross-contamination. We eliminated that risk by ensuring that no two runs ever touch each other.

Every single automation triggers a dedicated, headless browser instance spun up on demand via Google Cloud Run.

• Private Network: These instances live inside Stitchflow's private VPC.
• No Public Egress: Automation traffic never touches the public internet unnecessarily; it stays within our hardened network.

How we handle your credentials

We know that handing over admin credentials requires immense trust. We designed our credential architecture so that even we can't see them.

We use API-grade credential vaulting:

• Encryption: All secrets are AES-256 encrypted and stored externally in GCP Secret Manager or 1Password.
• Runtime Injection: Credentials are only injected at the exact moment of execution and are never stored persistently in the browser environment.
• Blind Access: Our engineers have no access to plaintext credentials.

Security in the Human-in-the-Loop

This is the part that usually raises the most questions. Stitchflow guarantees resilience by having a 24/7 Human-in-the-Loop (HITL) team intervene if an automation breaks (due to a UI change, CAPTCHA, or MFA prompt).

How do we put a human in the loop without breaking security?

We built a "clean room" for our engineers.

When an anomaly is detected, the automation pauses and alerts our on-call team. The engineer steps into a secure, sandboxed environment.

• No Credential Access: The system injects the credentials from the vault. The engineer never sees, copies, or types them.
• Video Audit: Every single human and browser action is recorded with a full video capture and timestamped log.
• Least Privilege: Access is governed by strict SSO and RBAC policies.

The problem with manual provisioning is that you can't audit a person clicking around a website. You can audit Stitchflow.

We are fully SOC 2 Type II certified. We don't ask you to trust us; we provide the independent assurance that proves our controls work.

We've measured the cost of manual provisioning across 27 organizations: ~$12,000 per app per year in IT labor, unused licenses, and compliance gaps. Stop choosing between the security risk of manual spreadsheets and the reliability risk of brittle scripts. You can have the security of an API, even when the vendor refuses to give you one - at a fraction of what manual work costs.