Kizma

Trust Center

Clear boundaries for controlled AI software work.

Kizma keeps workspace identity, human approval, evidence, and permanent history separate from agent execution and repository access.

Access model

Identity and membership are resolved on the server.

Fail closed

Authenticated private-beta requests use the active workspace membership selected for the signed-in user. Missing, invalid, inactive, or cross-workspace sessions are denied. Roles submitted by a browser are not trusted.

Technical access details
  • Row-level security scopes durable records to an active workspace membership.
  • Workspace switching re-resolves membership on the server.
  • Owner, admin, reviewer, member, operator, and viewer permissions remain action-specific.
  • Production activation and production identity operations remain blocked.

Membership and role changes are made inside an authenticated workspace.

Data handling & retention

Kizma stores control-plane records, not hidden execution data.

The authenticated workspace can hold identity, membership, repository and provider metadata, Tasks, routing recommendations, approval decisions, Work Records, verification records, and audit events. Repository source, raw provider payloads, credentials, and secret values are not part of these customer projections.

Customer retention, deletion, backup, and recovery policies are not yet offered as production guarantees.

Data lifecycle limitations
  • Browser-local inputs may remain according to the browser feature that created them.
  • No automatic deletion promise should be inferred.
  • No backup, recovery, residency, or retention guarantee is claimed.
  • Production lifecycle runbooks remain a prerequisite.

Encryption & isolation

Workspace isolation is enforced without overstating encryption.

Workspace scoped

Hosted application traffic uses HTTPS, and durable workspace tables use row-level security. Local and isolated hosted-staging validation covered tenant isolation; that validation is not a production security certification.

Encryption and secret-handling details
  • Kizma does not claim application-level field encryption or end-to-end encryption.
  • Provider encryption-at-rest capabilities are not restated as Kizma guarantees.
  • Privileged database credentials are excluded from normal application runtime.
  • Public diagnostics return safe status codes and booleans rather than secret values.

Audit & evidence

Human decisions and task history remain traceable.

Task history links server-resolved actors, approval decisions, Work Records, and safe evidence references. Audit events cannot be edited or deleted through the application.

Evidence intake is not verification, internal consistency is not proof of code correctness, and approval does not authorize execution.

Evidence integrity details
  • Audit writes are append-only through the application boundary.
  • Verification records stay distinct from evidence labels and provider output.
  • No claim of immutable, complete, certified, or production-grade audit coverage is made.
  • Human approval remains required wherever the Task says it is required.

Workspace history is readable inside an authenticated workspace.

Agent & repository boundaries

Metadata and recommendations do not grant access.

Execution disabled

Repository boundary

No repository read, content fetch, write, check, comment, branch change, or automatic merge is enabled.

Agent boundary

No provider is assigned, contacted, dispatched, or executed. No command or shell transport is active.

Connection and transport details
  • Repository and provider connection records are metadata-only until separately authorized and verified.
  • Recommendations describe modeled fit, not provider quality, speed, or availability.
  • Human approval cannot override a kill switch or enable an unavailable transport.
  • GitHub posting, verification execution, provider execution, billing, and automatic merge remain disabled.

Repository posture and the agent roster are visible inside an authenticated workspace.

Compliance & current status

Private beta, with certification claims withheld.

Not certified

Kizma does not currently claim SOC 2, ISO 27001, HIPAA, PCI DSS, FedRAMP, GDPR compliance, or another formal certification or legal compliance status.

A public security contact is not published. Use the communication channel agreed for the private-beta review.

Current production prerequisites
  • Review an approved production Supabase target and repeat Auth, RLS, isolation, and durability validation there.
  • Review production session lifecycle, rotation, recovery, and owner bootstrap operations.
  • Review production persistence failure behavior, monitoring, retention, backup, and recovery.
  • Review GitHub installation ownership and least-privilege repository permissions.
  • Enforce task-specific capability packages at a server authorization boundary.
  • Security-review every agent/provider adapter before connection.
  • Provide execution isolation, network controls, kill switches, and revocation.
  • Establish evidence provenance and integrity controls.
Become a design partner