Security and architecture
How Blackwing handles your data.
Most vendors answer security questions with reassurance. We’d rather show you the architecture and let you check it.
Blackwing was built for communications teams handling material that isn’t public yet — results under embargo, changes not yet announced, executive quotes still in approval. The design assumptions follow from that.
Your data is separated physically, not by a filter
Every customer gets its own database. Not a shared table with a customer-ID column and a filter on every query — a separate database.
This is the first thing a reviewer asks about, and the difference matters. In a shared table, one missing filter in one query is a data breach. There’s no equivalent single mistake here, because your data isn’t in the same place as anyone else’s to begin with.
Your search index is separate too, for the same reason.
And if the system can’t positively identify which customer a request belongs to, it refuses the request. It doesn’t fall back to a default. An unrecognized customer is an error, never a guess.
Files are encrypted at rest
Uploaded documents and images are encrypted with AES-256-GCM: a unique initialization vector for every file, and an authentication tag checked on every read, so a file altered on disk fails to open rather than opening wrong.
The application refuses to start in production without its encryption key configured. There’s no “temporarily disabled” state to forget about.
Who can reach what
- Role-based access, with a separate operator tier your administrators can’t reach.
- Per-module permissions. An account is granted only the parts of the product it needs, not all or nothing.
- Enforced at the endpoint, not in the menu. An administrator chooses which tools each account sees, and the endpoints behind them check the same grant, so an account denied a tool can’t reach it by another route. Hiding the button isn’t an access control, and we don’t treat it as one.
- Guests are contained. Someone invited to comment on one edition is confined to that edition. They can’t reach the wider workspace, can’t publish, and can’t export.
A record of what happened
Every significant action is recorded centrally and stamped with the customer it belongs to. Your administrators can read your audit trail, and only yours.
What it isn’t, plainly: the trail is complete and scoped, but it isn’t cryptographically sealed, and there’s no export or SIEM feed yet. Both are on the list in section 9.
Addresses you paste are checked before anything is fetched
Blackwing fetches web addresses on your behalf — an article someone pasted, an image imported from a story page. Before it does, it checks where the address actually leads and refuses anything pointing at internal systems rather than the public web.
Any tool that fetches a URL a user typed is a possible route into the network it runs on. This is the control that closes it, and it’s the one your reviewers will ask about by name.
How AI model access is controlled
Blackwing sends text to an AI model to draft stories and to run its checks. That’s the first thing worth being precise about, because “you’re sending our internal communications to an AI company” is the question every reviewer asks first.
Every call that sends your text goes through one point in the code. No feature reaches out on its own. At that one point there is:
- an allowlist of permitted models — a model that isn’t on it can’t be called;
- a cap on response size, which clamps an oversized request rather than failing it;
- per-customer cost accounting for every call.
Rate limiting is applied on the routes that reach it. An administrator can change these controls without waiting for a software release. This is checkable, which is the point. Reassurance isn’t.
Editorial controls that are also security controls
- Nothing publishes itself. Approval gates and sign-off are part of the workflow, not an optional add-on.
- Claims are traceable to the source they came from, so a disputed line can be checked against the material the writer was actually given.
- Compliance checking runs before publication, against categories your administrators define.
How we build
- Continuous integration runs the type checker, the full test suite, and a dependency vulnerability scan on every change.
- Automated secret scanning blocks credentials from entering the codebase.
- Security-relevant behavior is covered by tests written specifically to fail if a control is weakened, so a protection can’t be quietly removed without the build going red.
Certifications: where we actually are
Blackwing holds no security certifications today. We’re not going to imply otherwise.
What doesn’t exist yet
No SOC 2, of any type. No ISO 27001. No penetration test has been performed. Not yet in the product: multi-factor authentication, automated user provisioning, a data-subject export or erasure capability, and an audit export or SIEM feed. We don’t publish uptime figures, because we haven’t measured any.
Our position, plainly
Certification is an audit of controls, and it costs a substantial amount of money and several months. The controls themselves are what protect your data, and those are built and tested now — this page describes them, and we’ll walk any reviewer through the code behind each one.
We’ll pursue formal certification when a customer’s procurement requires it, and we’d rather scope it against a real contract than spend a year certifying against a guess. If you need a specific standard, tell us which one and we’ll talk about timelines.
When that work starts, this page will say so — with the standard, the auditor, and the date. Not before.
Questions from a security reviewer are welcome.
We’ll answer them in specifics. If your team has a questionnaire, send it — we’ll fill it in honestly, including the parts where the answer is “not yet.”
Book a demo