The controls, described precisely.

The governance model

SenangAI treats governance as part of the request path rather than a policy applied around it. A question travels through five checks before an answer is produced, and every one of them can stop it. There is no administrative mode that bypasses this path, and no configuration that disables it for a workspace, because the checks are how retrieval is implemented rather than a layer in front of it.

The practical consequence is that governance failures show up as missing answers, not as leaked ones. A question that falls outside a person's scope returns nothing and produces an audit record. This is deliberate, and it is the behaviour most worth testing during an evaluation.

Scope and permissions

Knowledge lives in one of three boundaries. Organisation scope holds material the whole enterprise may read. Teamspace scope holds material shared within a defined group. Personal scope holds an individual's own context and is not readable by administrators through the product interface.

• Scope is evaluated before retrieval, so unpermitted material is never loaded into a model's context, not merely filtered from the output.
• Permissions on connected sources are read from the source system rather than reimplemented. If a document is restricted in the system of record, it stays restricted here.
• Agents and workflows inherit the scope of the workspace they are created in. An agent cannot hold broader permission than the person who created it.
• Denied requests fail closed. The answer is empty, the reason is recorded, and no partial content is returned.

Provenance and citations

Every passage retrieved carries its origin: the source system, the document, the location within it, and the version in force at the time. Citations shown with an answer resolve back to that origin, so a reader can open the underlying document and a reviewer can confirm months later that the answer reflected what the document said at the time.

Where an answer cannot be grounded in permitted sources, the platform says so rather than composing something plausible. An ungrounded answer is a defect, and the insights view reports the proportion of answers carrying citations so you can watch that number rather than trust it.

Approval and action

Answering and acting are governed differently, because their consequences differ. Retrieval is bounded by scope. Action is bounded by a person.

• Agents and workflows are created in a paused state. Creation is not activation; someone with authority must activate them deliberately.
• An approval node halts execution and waits. It does not time out into approval, and it cannot be satisfied by another agent.
• The approver's identity, decision, timestamp and rationale become part of the audit record for that run.
• Rejection is a first-class outcome and is recorded with the same detail as approval.

Audit and evidence

The audit trail records what was asked, which scope was evaluated, what was retrieved, which model handled the request, what it cost, what action followed, and who approved it. Denied attempts are recorded with the same fidelity as successful ones.

Records are exportable for internal review or external audit. Evidence is produced as work happens, not reconstructed on request, which is the difference between an audit trail and a log file.

Data handling

• Retrieval is local. Search and ranking run inside your deployment boundary. Document content is not sent to a third-party search service.
• Your content is not used to train models. Neither ours nor a provider's. This holds in every deployment mode.
• Encryption in transit and at rest, with key management appropriate to the deployment mode you choose.
• Tenant isolation in hosted deployments; complete physical isolation on-premise, where no component calls out unless you configure it to.

Personal data & PII

Personal information gets its own treatment, because privacy obligations do not pause for AI adoption. The platform can detect and mask personally identifiable information in text before it travels further — and, unusually, the masking itself is evidence: every redaction is logged per entity, recording what was masked and why. Silent redaction is a black box; logged redaction is something you can show a regulator.

• Redaction runs inside your boundary. Text is not sent to a third-party service to be cleaned; the capability runs where the platform runs.
• Agents get it by allow-list. Redaction is a capability you grant, so you decide which workflows must mask personal data before producing output.
• Personal scope stays personal. Individual matters live in a boundary administrators cannot browse through the product, while organisation scope answers the policy question.
• Redaction events join the audit trail alongside everything else, so data-minimisation practice is demonstrable, not asserted.

This supports obligations you already carry under privacy law — data minimisation, purpose limitation, demonstrability. As with certifications, we describe what the platform does rather than claiming a badge: bring your privacy counsel to the walkthrough and we will map the capability to your specific obligations.

Model policy

You register which models are permitted to run. Nothing else runs. That registry may hold open-weight models inside your own infrastructure, models in a sovereign region, or approved commercial APIs — and it may hold different answers for different workspaces if your policy distinguishes them.

Within the permitted set, requests are routed to the cheapest capable model. Routing is recorded per request, so the audit trail always shows which model produced a given answer. If your policy forbids a model, it is not a fallback — it is absent.

Deployment isolation

• On-premise. Platform and models run inside your network perimeter. The strongest isolation available, and the right answer where data residency is a legal constraint rather than a preference.
• Private cloud. Deployed into your own tenancy or a sovereign region, under your credentials and your network policy.
• Hosted. Managed by us with tenant isolation. Appropriate for evaluation and for organisations without residency constraints.

The control model is identical across all three. A decision made during a hosted evaluation does not have to be revisited when you move on-premise, and the knowledge layer does not need rebuilding.

Retention and deletion

Deletion propagates. Remove a document and everything derived from it goes too — not just a search entry — and the removal itself is recorded. Retention periods for conversations and audit records are configurable to match your own policy, including where that policy requires records be kept longer than you might prefer.

Shared responsibility

Some things are ours and some are yours. Being unclear about the boundary is how deployments go wrong.

• We are responsible for enforcing scope at request time, producing accurate provenance, honouring the model registry, recording the audit trail, and the security of the platform we ship.
• You are responsible for defining the boundaries correctly, deciding which sources are approved, choosing who may approve what, setting budgets, and the security of infrastructure you operate.
• We share connector configuration, directory integration and the design of the first workflows — which is most of what the evaluation period is for.

Certification status

We would rather state this plainly than imply more than we hold. Formal certifications are in progress, and the current status is specific enough that it belongs in a conversation rather than on a marketing page — ask us directly and we will tell you exactly where each one stands, including the ones we have not started.

What we can provide today: architecture documentation, the data-flow description for your chosen deployment mode, our security questionnaire responses, and a technical brief for your security team. Where a control matters to you and does not exist yet, we will say so rather than describe a roadmap as a feature.