Security

Effective October 19, 2026 · RuneSpoke Inc.

In short. SOC Binder holds read-only access to your cloud accounts — and, only if you opt in, a separate role for approved fixes — and the evidence your audit depends on, so we keep access narrow, encrypt what matters, and tell you plainly what we have and have not done. We are not yet SOC 2 audited ourselves, and we say so below.

1. Read-only by default

AWS. You create a role in your own account using AWS’s managed SecurityAudit policy, which can read configuration but not change it. We reach it with a unique external ID for your organization, and our servers may assume only roles with that template’s name. We do not read the contents of your S3 objects, databases or logs.
GitHub. The integration only makes read requests, and never reads source code, commits or pull requests.
You can cut our access at any time by deleting the role or revoking the token. You do not need us to do it.

2. Binder Fixes, only if you opt in

Fixing uses a separate role, generated from our list of fixes, that can make only those specific changes. Evidence is never collected through it.
Every fix is previewed against the live setting. Approving one needs an owner or admin to enter a fresh two-factor code; high-risk fixes always need approval, whatever your settings.
We use short-lived (15-minute) credentials for one approved fix at a time, named after it, so your own AWS CloudTrail shows exactly which fix made each change.
Every step is written to an append-only audit trail in which each entry is cryptographically chained to the one before, so an edited or deleted entry is detectable; the Binder Fixes page checks it every time it loads.
After a fix, we re-check with the read-only role and mark it verified only when fresh evidence shows it worked.

3. The SOC agent (AI)

Off unless enabled for your organization. When it runs, summaries of failing checks are sent to Anthropic’s API, which may not train on them under its commercial terms.
It can only propose fixes from the same list, through the same approvals. Evidence it reads is treated as data, never as instructions.
An organization may use its own Anthropic API key. Only the owner can add one, with a fresh two-factor code; it is tested before it is saved, encrypted with AES-256-GCM like every other credential, and never displayed again beyond its last four characters.

4. Encryption

In transit. HTTPS only, with automatic TLS certificates and HTTP Strict Transport Security; plain HTTP is redirected.
At rest. The server’s disk and our backups are encrypted.
Credentials you connect — your AWS external ID and GitHub token — and two-factor secrets are additionally encrypted by the application with AES-256-GCM before they reach the database. The key is held in AWS Systems Manager Parameter Store, not in the code or the database.

5. Accounts and access

Passwords are at least 14 characters with upper and lower case letters, a number and a symbol; may not contain your email address or company name; are checked against known data breaches (only a fragment of a one-way hash ever leaves our server); and are stored only as scrypt hashes.
Two-factor authentication with any authenticator app, plus single-use recovery codes; or, if your organization allows it, a code texted to a confirmed US or Canadian number. Required for every account: nothing in SOC Binder opens until it is set up, and it can be moved to a new phone but not switched off. People whose organization requires its own single sign-on get it from their identity provider instead.
No account can be used until its email address is confirmed.
Sign-in with Google, Microsoft or GitHub uses the authorization-code flow with PKCE. A provider account is only ever connected by someone already signed in, never matched to an existing account by email, and two-factor still applies.
SAML single sign-on with your own identity provider (Okta, Microsoft Entra ID, Google Workspace and others). Assertions must be signed by the certificate you configure, addressed to us, answer a request we made, and be used once; only addresses on email domains you have verified by DNS can sign in. You can require it for everyone but owners, who keep a password so a broken identity provider cannot lock you out.
A password reset needs the emailed link and the second factor you already have, so access to your inbox alone is not enough to take over your account.
Approving Binder Fixes and other sensitive changes always needs an authenticator-app code, never a text: a phone number can be stolen from its carrier.
Sessions are server-side and can be revoked. They expire after 7 days, or 12 hours unused. A password reset signs out every other session, and so does changing your two-factor or connecting a sign-in method, which also gives this one a new identifier. You can sign out everywhere from your Security page.
Sign-in, sign-up, password reset and two-factor attempts are rate-limited.
Every organization’s data is separated in the application, and an automated check on every code change fails the build if a database query could reach another organization’s data.
Auditor share links are read-only, expire, and can be revoked. They cannot act as a user.

6. The application

A strict Content Security Policy: the browser runs only our own scripts, and the site cannot be framed by others.
No third-party scripts, analytics or trackers.
Uploaded evidence is limited in size and type, and always downloaded as a file — never rendered in the page.

7. Infrastructure

Hosted on Amazon Web Services in AWS US East (Ohio), us-east-2, in a dedicated AWS account used only for SOC Binder.
The database is not reachable from the internet; only the web server is.
Instance metadata requires session tokens (IMDSv2); operating-system security updates install automatically.
Releases switch traffic to a new copy of the application only once it passes health checks, and can be rolled back.
Nightly database backups are encrypted, stored separately in S3, kept 35 days, and write-only to the server that makes them — it can add backups but not delete them.

8. How we build it

Every change runs type checks, linting, an automated test suite, static analysis for security flaws, a dependency vulnerability audit and a scan for committed secrets.
New versions of open-source dependencies are not adopted until they have been public for seven days, to avoid freshly compromised releases.

9. Certification — honestly

RuneSpoke Inc. has not been through a SOC 2 examination, and we do not claim to hold a SOC 2 report or any other certification. We are working toward one. We are happy to answer a security questionnaire in the meantime.

10. Reporting a vulnerability

Email security@socbinder.com with enough detail to reproduce it. We will acknowledge within 2 business days, give an initial assessment within 5, keep you informed until it is fixed, and credit you if you wish.

We will not pursue legal action against anyone who reports in good faith, does not access or alter other people’s data, and gives us reasonable time to fix the issue before disclosing it. Please do not run automated scanners or denial-of-service tests against the service, or attempt social engineering.

If you suspect your own account has been compromised, also email security@socbinder.com. More on how we handle personal information is in our Privacy Policy.