Build capacity before adding payroll — here's the arithmetic

7astrixBook a teardown

Security & control

Agents prepare the work. People approve it.

This is the part regulated buyers actually care about, so it gets its own page rather than a line in the footer. If your risk team wants to review any of it before a first call, send them here.

The controlling rule: nothing we build has authority to move money, make a decision about a client, or send client-facing output unreviewed. Automations prepare, reconcile, draft and flag. A named human with existing authority approves. Every action is logged with a timestamp, the data it used, the rule it applied and the outcome, and the log exports for your auditor.

Controls

Six things we hold to on every engagement.

No agent moves money

Ever. Automations prepare payment runs, draft entries and flag exceptions. Releasing funds and posting final entries requires a named human. That's a design rule, not a setting someone can toggle.

Everything is logged

Each action is recorded with a timestamp, the data it used, the rule it applied and the outcome. The log is exportable, and your auditor can read it without us in the room.

Maker and checker stay separate

Approval hierarchies mirror your existing delegation of authority. If a person can't approve something today, the system can't either. We map this before we build, not after.

Least-privilege access

We take the narrowest permissions that will do the job, scoped per system, documented, reviewed quarterly, and revoked the day an engagement ends.

Your infrastructure, your data

Orchestration is self-hosted where your policy requires it. Client data isn't used to train anything and isn't pooled across clients. Providers are named in your documentation.

Clean exit, in writing

If you leave, you keep the systems, the documentation and the runbooks. We revoke our own access and hand over. Nothing we build is designed to trap you.

Being straight about it

Where we are, and where we're not yet.

Security pages usually imply more than they say. Ours states the position plainly, because a procurement team will find out anyway and we'd rather they hear it from us.

Insurance

Current coverage is stated in the proposal and evidenced during procurement. No policy or coverage level should be inferred from this website.

Certifications

None are claimed on this website. If that changes, the certification, scope and date will be published precisely rather than implied.

Subprocessors

Every third party touching your data is named in your build documentation, with what it does and why. No unnamed dependencies.

Incident handling

Defined escalation path and named contact, agreed before go-live rather than improvised during an incident.

Questions

What risk teams ask.

Does AI ever touch our bank account?

No automation we build has payment-release authority. Systems prepare payment runs and flag anomalies; a named person with existing authority releases funds. Where a platform technically allows automated payment, we disable it and note that in the build documentation.

What happens if an agent gets something wrong?

It lands in an exception queue rather than in your ledger. Confidence thresholds are set deliberately conservative at go-live and loosened only once we have measured real accuracy on your data. Anything below threshold routes to a human, and recurring misses get fixed at the root rather than handled forever.

Is our data used to train models?

No. Client data is not used for training and is not pooled across clients. Where we use third-party model providers, we use configurations that exclude data from training, and we will name the providers in your build documentation.

Can our auditor review this?

Yes, and they should. Logs are exportable and readable without us in the room, the control design is documented, and we're happy to sit on a call with your auditor or your client's risk team. We have no interest in being the part of your stack nobody can explain.

What access do you actually need?

The narrowest set that does the job, scoped per system and documented. In many engagements that means read access to the ledger and write access to a single clearing account or a draft-entry queue, not administrator rights.

What happens to everything if we leave?

You keep it. Systems run on infrastructure you own, documentation is written during the build rather than promised after, and we hand over runbooks and revoke our own access. Thirty days' notice on the retainer. Nothing we build is designed to be difficult to leave.

Next step

Send us your security questionnaire.

We'd rather answer it before you've spent time on a call. Send it over, or book fifteen minutes and bring your risk lead.

We reply within one business day. No sequence, no newsletter signup, no follow-up from a tool.