Security

Signal 7 holds things that matter to a brand: its material, its voice, its connected accounts and its provider keys. We protect them in layers, and where we can we enforce a rule with an automated check that fails our build, so it does not depend on someone remembering it.

We do not hold security certifications or third-party audit reports today. This page describes what the Service does, not a guarantee; no system is perfectly secure.

• In transit. The Service is served over HTTPS (TLS) in production, and our connections to providers use TLS.
• Provider keys (BYOK). A brand’s own AI and media keys are checked with the provider before they are stored, encrypted with AES-256-GCM, decrypted only on the server at the moment of a call, and never returned to a browser or shown again.
• Connected accounts. Access and refresh tokens for social networks, ad platforms and sites are encrypted with AES-256-GCM before they are written.
• Encryption keys are held in our hosting environment’s secret configuration, separately from the database.
• Passwords are stored only as bcrypt hashes. MCP and API keys are shown once and stored only as a SHA-256 hash and a short display prefix.
• At rest. Our database and file-storage providers encrypt stored data at rest.

Every brand and organisation has roles (owner, admin, user, viewer). Each request is authorised on the server against the signed-in person’s role in the brand it touches; nothing relies on the browser hiding a button. An automated check fails our build if a route that reads or changes a specific record shows no authorisation check.

Brand administrators control members, keys, connected accounts, spend caps, which AI models may be used, and output moderation. A brand’s keys are only resolved for requests that have passed its access check. Administrators see totals for their scope, not members’ IP addresses.

Access by our own staff to customer data is limited to the people who operate the Service, for support, security and the duties described in our Privacy policy.

Approval gates. Automatic publishing is off by default for every brand. A piece with a review pending or changes requested is held; a rejected piece is never published. Changes proposed through an MCP key are staged for review and never applied on their own.

The agent trail. When an agent acts for a person — an MCP tool that writes, a flow step, a bot command, the property assistant, the scheduled publisher — one record says what was done, for which brand, by whom and what it touched. It holds references, not content. Our database client refuses to update or delete these records. Brand administrators can read their brand’s trail.

Guard rails on spend and output. Each brand can set a monthly AI spend cap, which is checked before a call is made, and a list of models it will not use. Output leaving the Service for people who did not write it is checked by automated moderation, which records a flag or blocks it according to the brand’s setting.

• Sign-in attempts are rate-limited, and many failed attempts on an account raise an alert.
• The session cookie is HTTP-only and, in production, secure.
• You can see every session and device on your account and end one, or all others, from Settings or your Usage page. Ending a session revokes its tokens and those of any paired device.
• We alert you by email, in the product and, if you have linked it, on Telegram when a session starts from a new device, a new country, or a VPN, proxy, hosting or Tor network you have not used before, or when it implies impossible travel since your last session.

What we record about sessions, and for how long, is set out in the Privacy policy.

Each key carries scopes (read, generate, propose changes, administer) and a lens that limits what brand knowledge it can see: creative (identity, voice, visual system, products; no metrics, operations or strategy), strategy, or full, which still never exceeds what the brand has enabled. Only what a key carries is checked; issuing it under a named persona confers nothing extra. Brand administrators can revoke keys at any time.

• Server-side requests. When the Service fetches a URL a user supplied, the address is checked against private and internal networks at every redirect, and an automated check fails our build if a request bypasses that guard.
• Webhooks. Incoming webhooks from payment and email providers are verified by signature before they are acted on; internal machine-to-machine calls use shared secrets compared in constant time.
• Rate limits protect sign-in and other sensitive endpoints.
• Every change runs through an automated test suite and a set of security lints in continuous integration.

The application runs on Railway. The database is MongoDB Atlas; media files are stored in Cloudflare R2; DNS and network edge are Cloudflare; payments are handled by Stripe, which holds card data so we never do. The full list of providers is in the Privacy policy. Database backups are taken daily and each is kept for 30 days. Data you delete may remain in those backups for up to 30 days before it is overwritten.

When we detect or are told of a possible security incident, we investigate, contain it (for example by revoking sessions and keys and rotating secrets), and fix the cause. If personal data was affected, we notify affected customers without undue delay and the authorities where the law requires, and tell customers what we know and what they should do. Customers who process others’ data through Signal 7 will receive what they need to meet their own obligations.

Please report security issues to security@signal7.io with enough detail to reproduce them. We will acknowledge your report, keep you updated, and tell you when it is fixed.

While investigating, please:

• test only against your own account and data, and stop as soon as you reach anyone else’s;
• do not degrade the Service (no denial-of-service, load or spam testing), and do not use social engineering or physical attacks;
• do not keep, share or publish data you encounter, and give us reasonable time to fix an issue before you discuss it publicly.

If you follow these rules in good faith, we will not pursue legal action against you for your research. We do not currently run a paid bug bounty.

Security: security@signal7.io. Everything else: hello@signal7.io.