Written for the person who blocks the deal.
This page exists for security reviewers, IT leads and procurement. It states what is true, what is not yet true, and where the boundaries sit — because the questions below decide whether a project clears review, and answering them at week six is worse than answering them now.
Authorization is a platform service, not application code
The most common security defect in generated software is a permission that was implemented in the application rather than enforced by the system underneath it. Genwright applications do not implement their own authorization.
Role-based access
Roles are defined per deployment and applied to every surface. A role's reach is a property of the platform configuration, testable independently of any screen.
Row-level security
Access is enforced per record, not per table. A contractor sees their own work, a district office sees its own county, an auditor sees everything read-only.
Enforced audit trail
Creation, amendment, author, timestamp and prior value, captured at the platform layer on every record. Not an optional module and not switchable off per application.
Ask for a role matrix and try to break it. Every role against every surface is exactly what pre-flight checks before an application can reach production, and the results are recorded per promotion.
Where model access begins and ends
This is usually the first question a reviewer asks about an AI-built system, so it is stated plainly.
Builders run the client
Building happens through Anthropic's official Claude Code client, run by your builder, authenticated with your organization's own Anthropic account. Genwright does not distribute a modified AI client.
Knomatic provides tools, not prompts
Claude Code connects to the Knomatic platform over an MCP server. Knomatic sits on the tool side of that connection: it exposes platform capabilities to a client you operate.
Model usage is your billing relationship
Your Anthropic credentials are held by your client. Model usage is billed by Anthropic to you, at your rates. There is no Genwright credit system and no resold AI capacity.
Building happens away from production
Build connections are scoped to a build environment. Production is not a build target; changes reach it only by promotion through pre-flight.
Where it lives, who can reach it, and how you get it back
Operational data lives in your deployment on Knomatic infrastructure, with backups, monitoring and environment separation as platform properties rather than per-application choices.
Export is a platform capability in standard formats, not a support request and not a negotiation. A system you cannot leave is not a system you can safely depend on, which is why ownership and exit has its own page rather than a paragraph in the terms.
Data residency, retention periods, deployment isolation and subprocessor detail are deployment-specific and are covered in scoping and in the contract documents rather than asserted generically here.
Residency, isolation model, retention, backup and restore targets, and the current subprocessor list. These are answerable in writing before you commit to anything.
What we can evidence today, stated honestly
A security page that overstates its position gets found out in the first review call, so this section says what is actually the case rather than what would read better.
Available now
Platform architecture documentation, role and permission model detail, the pre-flight inspection scope, backup and environment separation design, and the AI boundary described above — all reviewable under NDA during scoping.
In progress
[CONFIRM AND REPLACE: current SOC 2 status and timeline, or remove this block entirely. Do not publish an unverified compliance claim.]
Security review questions
Does Knomatic have access to our operational data?
Knomatic operates the platform your deployment runs on, so support and infrastructure staff have the access that operating a hosted platform requires, governed by internal controls. The specific access model, logging and retention for your deployment are covered in the contract documents and reviewable during scoping rather than described generically on a marketing page.
Is our data sent to an AI provider?
Building happens through your own Anthropic account via Claude Code, which is how build-time context reaches a model. What that context includes is scoped to the build environment rather than production records, and the specifics should be reviewed with your team during scoping. Running applications do not require model access to operate.
Can we run a penetration test?
Testing arrangements are agreed in writing before they begin, including scope, window and disclosure handling. Bring this up during scoping rather than after contracting, because the answer affects the timeline.
What happens to our data if we leave?
Export in standard formats is a platform capability available throughout the relationship, not only at the end of it. Retention and deletion after termination are governed by the contract documents. See the ownership page for the fuller answer.
Who do we contact about a vulnerability?
Raise it on a scoping call or through your existing Knomatic contact, and expect acknowledgement before public discussion. A dedicated disclosure address will be published once there is a monitored intake and a named triage owner behind it — an unanswered security inbox is worse than none.
Bring your reviewer to the first call, not the fifth.
Security review is usually what determines a project timeline. We would rather surface the blocking questions at the start than discover them at week six.