Security at the system level.
Security requirements are determined by the information a system processes, the operations it performs, and the external services it depends on.
Our approach addresses identity, authorization, data isolation, operational integrity, and external connectivity at the architectural level.
Pillars
Four pillars, built into the platform.
How the systems protect an agency’s data, its access and the model that works with both.
- Isolation
- Tenant isolationRow-level security policies on the database scope every query to one organization. No model is trained on your operation.
- Encryption
- In transit and at restTLS on every connection. AES-256 on stored data and backups.
- Context
- Context on demandJanus is built to retrieve per request: only the records a task needs, scoped to one organization. Credentials stay in an isolated vault and never enter the model’s context.
- Abuse protection
- API abuse protectionBuilt with per-key rate limits and automatic blocking at every endpoint. Integrations listen for events instead of polling, and back off when nothing has changed.
// every request carries one organization; nothing crosses const scope = await orgFromSession(req); // per-key limits; repeat offenders are blocked await rateLimit(key, { window: "1m", max: 120, block: "15m" }); // no blind polling: wait for events, back off when quiet onEvent("record.updated", sync); retry(sync, { base: 1_000, factor: 2, max: 60_000 }); // the model never sees a secret const ctx = await retrieve(task, { scope, exclude: ["credentials"] });
Controls
Five areas, addressed at the architectural level.
| Area | Principle | Implementation |
|---|---|---|
| 01Identity & authorization | Access is governed through defined roles, organizational boundaries, and session assurance requirements. | In BindOS, authorization is enforced through PostgreSQL row-level security policies, with organization, branch, and agent-level permissions. Multi-factor authentication is required on every sign-in; a correct password alone does not grant access. |
| 02Data isolation | Organizational data boundaries are enforced at the database layer, independently of interface-level restrictions. | Privileged background operations follow separate authorization paths, with access controlled according to their responsibilities. |
| 03Auditability & record integrity | Operational systems require traceability across changes, actions, and system events. | BindOS maintains a database-enforced append-only audit log, protected against modification and deletion through database triggers. |
| 04External integrations | External connectivity introduces distinct authentication, authorization, and data-integrity requirements. | Integration mechanisms are evaluated according to provider requirements, permitted access methods, credential handling, and the operational consequences of connection failures. |
| 05Infrastructure & data protection | System infrastructure is selected and configured according to operational requirements, data sensitivity, and availability considerations. | BindOS currently operates on managed cloud infrastructure, with PostgreSQL supporting its primary data layer. |
Controls, enforced by the database.
Authorization is evaluated per row in the database, not in application code. Capabilities resolve from a single permission model; the audit trail is append-only by trigger.
-- every row belongs to one organization; nothing crosses alter table policies enable row level security; create policy org_isolation on policies using (org_id = current_org()); -- the audit log is written once and never changed revoke update, delete on audit_log from app_user;
Engineering
Architecture follows the domain: its records, its authority, its failure modes.
Regulated records, delegated authority, dependencies outside our control. Each is modeled explicitly: invariants in the database, side effects behind typed boundaries, every external call designed for failure.
- 01Domain
Domain modeling
The domain is modeled before the interface: entities, lifecycles, and the authority to change them.
Lifecycles are explicit state machines. Invalid transitions are rejected at the data layer, not discovered downstream.
- 02Architecture
Invariants in the database
Business rules live where the data lives.
Constraints, triggers and server-side procedures define what every client must respect. Automation proposes; a licensed person confirms anything that becomes part of a policy or a sworn form.
- 03Security
Least privilege, lowest layer
Every control is enforced at the lowest layer that can enforce it.
Authorization is evaluated per row in the database, not in application code. Capabilities resolve from a single permission model; the audit trail is append-only by trigger.
- 04Resilience
Failure engineering
Every external dependency is assumed to fail.
Timeouts, expired sessions, partial writes, late or missing responses. Operations are designed to retry safely, fail closed, and hand off to a person with full context when automation cannot finish.
Security inquiries
Security inquiries.
For technical security reviews, integration assessments, and related institutional correspondence.