AIX security and operations

Security is enforced by application and infrastructure boundaries, independently of model behavior. A convincing model response never grants access or authorizes a mutation.

Trust boundaries

flowchart LR
    Browser[Authenticated browser] --> Gateway[Kesita app and Product API]

    subgraph Private[Private application boundary]
        Gateway --> Worker[Product worker + DBOS]
        Worker --> ProductDB[(Product PostgreSQL<br/>forced RLS)]
        Worker --> ProductBlob[(Private product blobs)]
        Worker --> Parser[Isolated parser]
        Worker -->|workload JWT| LegalCore[Legal Core]
        LegalCore --> LegalDB[(Legal PostgreSQL)]
        LegalCore --> Corpus[(Private corpus blobs)]
    end

    Worker -->|allowlisted egress| Providers[Approved providers]

Enforcement

• The API resolves the authenticated user and organization; client-supplied tenant IDs are never authority.
• Forced PostgreSQL row-level security and composite tenant keys back application checks.
• Product requests, workers, migrations, legal readers, and corpus writers use separate database roles.
• Legal Core and the corpus worker are the only owners of legal database and corpus access.
• Product files, legal originals, provider credentials, and signing keys remain private to their owning workload.
• Authorization is rechecked when data is read and again when a result or document revision publishes.
• Prompts, completions, document bodies, tokens, and credentials are excluded from ordinary logs and traces.

Retrieved documents and tool output are untrusted content. They can influence model reasoning, but they cannot add capabilities, change budgets, bypass permissions, or redefine deterministic policy. Citation inspection and lawyer review reduce legal risk; they do not eliminate prompt injection or guarantee correctness.

Publication gates

flowchart LR
    Candidate[Candidate result] --> Generation{Current generation?}
    Generation -->|no| Reject[Reject publication]
    Generation -->|yes| Access{Access still valid?}
    Access -->|no| Reject
    Access -->|yes| Revision{Base revision current?}
    Revision -->|no| Conflict[Require merge or regeneration]
    Revision -->|yes| Evidence{Evidence valid?}
    Evidence -->|mechanically invalid| Reject
    Evidence -->|valid, limitations remain| Review[Publish as review required]
    Evidence -->|valid and assessed| Publish[Publish assessed draft]

Internal document proposals require explicit lawyer acceptance. Acceptance records the actor, proposal, task generation, and exact base revision. It is not permission for an external action.

Budgets and provider failures

PostgreSQL owns the AIX credit ledger and provider admission state. Each paid attempt reserves bounded exposure before execution and settles measured usage once. Synthesis and assessment retain protected capacity so research cannot consume the whole task budget.

If a provider times out without reliable idempotency or status lookup, its possible liability remains reserved for reconciliation. The system does not assume the call was free and does not automatically repeat it.

Operations and recovery

flowchart TB
    Signals[Logs, traces and metrics<br/>opaque IDs only] --> Detect[Detect stuck work, failed publication,<br/>provider saturation and unreconciled usage]
    Detect --> Restart{Ordinary restart?}
    Restart -->|yes| Replay[Replay durable recorded steps]
    Restart -->|cross-store restore| Fence[Fence old credentials and generations]
    Fence --> Reconcile[Reconcile tasks, blobs,<br/>permissions and provider receipts]
    Reconcile --> Decision[Explicit resume, retain or cancel]

Operational correlation uses request, task, operation, and trace IDs without logging legal content. Alerts should cover queue age, acceptance-to-start latency, retries, failed publication, suspended work, credit exposure, and durable-store health.

Backups of PostgreSQL, DBOS state, blobs, and external provider state do not form an automatic distributed snapshot. Restore therefore fails closed: old work is fenced, missing evidence remains unknown, and no affected task resumes without an explicit decision.

Verification boundary

Run scoped application and Go checks first, then the platform Hermit plan for real database roles, service authentication, durable execution, cancellation, clarification, document processing, and provider simulation:

pnpm --filter kesita-app test
pnpm go:test
./bin/hermit run tests/plans/platform/integration.yaml

Passing these checks does not prove real-provider legal quality, prompt-injection resistance, production network isolation, autoscaling, or cross-store disaster recovery. Those require environment evidence, recovery drills, and lawyer-reviewed evaluations.