Trust
Security
Archron holds write access to production business systems, so the controls below are the product, not a wrapper around it. Where something is not done yet, it says so.
Last updated: August 2, 2026
Not yet certified, and we do not claim to be. Archron has not completed a SOC 2 or ISO 27001 audit, and has not yet had a formal third-party penetration test. Both are planned. What follows describes controls that are live and enforced today, each mapping to a specific implementation and test in our codebase. Certification is a separate organizational process, and we will not imply we have finished it.
What Archron stores, and what it does not
Archron is middleware, not a system of record. That single design decision removes most of the data risk a security review usually has to work through.
| Data | Held by Archron |
|---|---|
| Business records from your CRM or ERP | No. They stay in your connected system |
| OAuth token material | No. Held in AWS Secrets Manager; the database stores only a reference |
| Card and payment details | No. Handled entirely by Stripe |
| Verification evidence | Yes, minimized to the fields an operation actually wrote |
| Schema and automation structure | Yes, org structure only, never record content |
| Audit history | Yes, append-only and hash-chained |
Tenant isolation is applied on every query. A cross-organization request resolves as not found, never as a denial that confirms the record exists.
The commit gate
No agent output mutates a business system directly. Every write follows the same pipeline: prepare, verify, explicit confirmation, commit, then post-commit read-back. There are no bypass paths, including for internal tooling such as administrator undo.
- Every commit requires a verification receipt. The receipt is single-use, time-bound, and fingerprint-matched to the exact verified intent using SHA-256. One verified decision authorizes exactly one commit and cannot be replayed.
- Confirmation is bound to a specific prepared operation. Preparing an operation mints a single-use token that the commit must echo. Re-preparing invalidates the previous token.
- Values must have a traceable origin. Every field value carries a deterministic provenance. Model guesses are rejected before the write is prepared, not after.
- Outcomes are observed, not assumed. Success is derived from reading the record back after the write, never inferred from a request that did not error.
Evaluating against a sandbox
You do not have to point Archron at production to evaluate it. The Salesforce package installs into a sandbox org as readily as a production org, and nothing about the setup changes when you later move across. Most teams should start there. The connection guide covers both paths.
Permission enforcement
Writes execute under the acting human's own OAuth credential. An agent's effective permissions in Salesforce or HubSpot are exactly that person's permissions, and nothing more. There is no shared service credential to fall back on, so an agent cannot inherit broader access than the person it is acting for. A user without a linked credential cannot trigger a write at all: the request is blocked and returned as a clarification.
An agent identity is never treated as a user account. Every request resolves to the acting human, with the agent recorded separately in metadata, so attribution survives into the audit trail. Field-level security is checked before any call reaches your system, so a write the acting user could not perform themselves is stopped in advance.
Where the commit gate applies
The commit gate governs agents that reach Salesforce or HubSpot from outside them: Claude, ChatGPT, Grok, or any other agent connecting through Archron's MCP server or HTTP API. It does not govern Salesforce's own native agent platform, Agentforce.
Agentforce actions run as Apex and Flow invocable actions inside Salesforce's own transaction. There is no external API call in that path, so there is nothing for an external governance layer, including Archron, to intercept. This is an architectural boundary, not a gap we have not gotten to yet: a native platform agent executing inside the platform's own runtime has no reason to leave it.
Agentforce has its own governance for that path: Salesforce permission sets and profiles, the Einstein Trust Layer, and guardrails defined in Salesforce itself. If your team runs both, the boundary is clean. Agentforce actions are governed by Salesforce's own controls. Anything connecting in from outside, agent by agent, is governed by Archron's commit gate.
Audit trail integrity
The audit trail is engineered so that altering recorded history is detectable, even by someone with privileged access.
- Append-only at the database level. Audit records can be inserted but never updated, deleted, or truncated. Enforcement lives in the database itself, so it applies regardless of the connecting application. The application cannot rewrite its own history.
- Cryptographic hash chain. Each entry is linked to the previous one with a SHA-256 chain maintained separately per organization. A removed row appears as a sequence gap and an edited row as a hash mismatch. An integrity verification routine reports exactly where a break occurs.
- WORM anchoring. The chain's latest state is periodically anchored to Amazon S3 Object Lock in compliance mode with a seven-year retention period. Once written, an anchor cannot be modified or deleted by anyone, including Archron and its cloud administrators, for the full retention period. Rewritten history would no longer match the anchored checkpoints, so tampering remains detectable even after a full database compromise.
- Chain heads can be anchored externally for independent verifiability, and undo operations are cross-linked in both directions on the trail.
One honest boundary worth stating: what is immutable is the record of actions. Your business data itself lives in the source system, where its own retention rules apply.
Infrastructure and encryption
- AWS ECS Fargate runtime with PostgreSQL on RDS in a private VPC, all in us-east-1.
- Database storage, Secrets Manager entries, and audit log objects are KMS-encrypted at rest.
- TLS for all external traffic.
- Automated database backups with deletion protection enabled on production.
- AWS CloudTrail with a multi-region trail and log file validation, Amazon GuardDuty for threat detection, and CloudWatch for runtime logs and metrics.
- ECR scan-on-push for every deployed image, and automated weekly dependency scanning with grouped security update pull requests.
- Changes land through pull requests. Continuous integration runs the full test suite, over 1,100 tests, plus lint and type checks before anything deploys.
We do not currently offer an EU-resident data option. We would rather say so than imply otherwise.
Internal access to customer data
Operator access is gated server-side rather than hidden behind a UI flag. Support impersonation sessions are time-boxed, and every action taken during one is tagged in the audit trail with the operator behind it. Cloud-side production access is limited to the founding team, and all AWS API activity is recorded by CloudTrail.
Your data, your control
- Export at any time. An owner or admin can export trace events, audit logs, operation sessions, members, and credential metadata. Token material is never included.
- Organization-wide erasure. Owner-initiated, confirmed by typing the organization name, with a thirty-day cancellable grace window. The erasure path is itself gated by a database function that refuses to run without a matured request for that exact organization, so a compromised application role cannot trigger it.
- Sealed deletion certificate. Erasure closes with per-table deletion counts, the pre-erasure audit chain head hash, and a statement of what was retained and why.
- Reversibility. Committed record changes can be undone from the audit log by an owner or admin, through the same verification pipeline as any other write.
Two limits we state rather than bury. Erasing a single data subject's values from within retained evidence is not yet supported; organization-level erasure is. And when you erase, Archron destroys its own stored credentials immediately, but provider-side OAuth grants may persist until expiry and must be revoked by you in that provider's admin console.
Incident response
Our process is detect, assess scope through the audit trail, contain by revoking credentials and tokens immediately, remediate, then notify. If we confirm a personal data breach, affected customers are notified without undue delay and within 72 hours, consistent with GDPR Article 33.
Responsible disclosure
Report vulnerabilities to security@archron.app. We acknowledge reports within two business days. Please give us a reasonable window to remediate before public disclosure.
Subprocessors
Amazon Web Services for hosting, database, and secrets. Stripe for billing. HubSpot for our own sales contact records. Vercel for marketing site hosting. Systems you connect, such as Salesforce or HubSpot, are reached through your own OAuth grants and remain your vendors under your agreements. See the privacy policy for details.
Full capability guide
Security reviewers can request the complete Security and Compliance Capability Guide. It contains the full control matrix, status for every control including the ones not yet implemented, the known limitations stated openly, and how these controls map to established frameworks.
Request the capability guide, or email security@archron.app directly.