Skip to content

Acceptable Use

Statement

This page documents what is and is not acceptable use of ClaimGuard's production systems by operators (the founder pair, engineers, and contractors with cloud-side or application-administrative access) and, separately, by end users of the application (customer staff authenticated into a customer tenant).

The policy is intentionally short. It is not the body of work that a larger organization would record under "acceptable use" — there is no formal end-user agreement (yet), no documented disciplinary process, and no broad device-management framework. What is recorded here is the rule set the founder pair operates under and the expectations encoded in the application's terms.

Implementation

Operator acceptable use

People who hold cloud-side IAM grants on train-cvit2 or administrative access in the application are expected to:

  • Use credentials only for ClaimGuard work. Workspace identities are not shared. Personal accounts are out of scope after A1.4-step1 cleanup, with one named developer-account exception.
  • Use IAP-SSH to reach the production VM. There is no other supported path. See Privileged access.
  • Use Secret Manager for secrets. Plaintext copies of production secrets on operator laptops are not permitted; any local .env files must be .env.local style and gitignored. See Secrets management.
  • Follow docs/security/PROTOCOL.md when changing security-relevant code paths. Branch-protected main and required PR review enforce most of this.
  • Record cloud-posture changes in docs/security/HARDENING-LOG.md with the standard What/Why/Commands/Verify/Notes shape. See Change management.
  • Report suspected security incidents internally to the founder pair, immediately. See Incident response.
  • Do not bypass review. PRs are not merged without review; cloud changes that affect production posture are not run without a journal entry.

End-user acceptable use

Customer staff authenticated into the application are expected to:

  • Not share credentials. Each user has their own account with their own password. API keys are bound to a single org and should be treated as credentials.
  • Not attempt to escalate role. The application's role checks are enforced server-side; attempting to bypass them is reportable under the Vulnerability Disclosure Policy.
  • Not attempt to access another organization's data. Org scoping is enforced at the SQL layer; an attempt to enumerate cross-org IDs is reportable under the same policy.
  • Not attempt to interfere with the AI integration. The guardrails described under Prompt guardrails are operator-side controls; attempts to circumvent them via claim- narrative content are reportable.
  • Use the security@dtectvision.ai channel for security-relevant reports rather than support channels.

These expectations live in the published terms of use the customer- business signs; there is no per-user click-through accept screen in the application UI today.

What is not in scope here

  • Endpoint device management for operators. Workstations are operator-owned; we do not run an MDM. Adding one becomes relevant at a larger team size.
  • Ban-list of acceptable software on operator workstations. Engineers choose their own tooling; the security model relies on Workspace-MFA-gated cloud access plus per-PR review of code that enters main.
  • Acceptable use of the AI integration by end users in customer workflows. That is governed by the customer-business's own AUP, not this page.

Status

partial — verified 2026-04-29.

What's in place:

  • A documented operator rule set, traceable across the trust portal to the controls that enforce each rule.
  • An end-user rule set encoded in the customer-business's contract and in the application's role-and-org enforcement.

Known gaps

  • No per-user click-through AUP at first application login.
  • No formal disciplinary or remediation process for an operator AUP breach. Today this would be handled bilaterally by the founder pair.
  • No endpoint device management for operators.
  • No documented training programme that walks a new engineer through this AUP.

Roadmap

  • In-application AUP screen at first login, recording acceptance in the user row. Useful evidence for SOC 2 / ISO and trivial to add.
  • Engineer-onboarding flow that includes an AUP read-and-sign step alongside docs/security/README.md.
  • Endpoint hygiene baseline for operators (disk encryption, screen lock, OS update) — written, not enforced.
  • MDM if the team scale or compliance scope demands it.