KAIDAN security and data boundaries

This page explains what KAIDAN is permitted to observe, how it treats evidence, and which claims it intentionally refuses to make.

Product boundary

Briard-AI is the governance, subscription, identity-entry, and add-on authorization experience. KAIDAN is the security and incident-forensics add-on.

KAIDAN is authoritative for:

• its tenant-scoped evidence ledger;
• source and connector receipts;
• case history and collaboration;
• security findings;
• custody verification; and
• evidence exports.

Briard-AI does not duplicate or silently rewrite those records. The eventual trust path maps identity and tenant server-side. A browser token or tenant identifier must never be forwarded merely because the browser supplied it.

Metadata-only normal intake

Permitted normal-intake examples include:

• event and receipt timestamps;
• pseudonymous actor, tenant, request, trace, deployment, tool, and source identifiers;
• model family or deployment metadata reported by an approved source;
• operation type and bounded outcome;
• policy or guardrail decision metadata;
• token or result counts when the approved source supports them;
• source package, schema, version, checkpoint, and health;
• custody, signature, digest, and export metadata; and
• case classifications, tasks, and human decisions.

Normal intake excludes:

• prompt or response text;
• uploaded files or document content;
• source code or repository file content;
• credentials, API keys, tokens, certificates, private keys, or kubeconfig;
• vectors, embeddings, retrieved documents, SQL text, or bind values;
• raw account, cluster, collection, tenant, or personal identifiers when pseudonymization is required;
• command lines, environment variables, window titles, or browser URLs; and
• regulated or customer production content.

A privacy filter is a control, not permission to send prohibited content. Configure the source to exclude it before transmission.

Restricted forensic capture

Restricted capture is for a separately authorized investigation that genuinely requires content-bearing evidence. It is:

• disabled by default;
• outside normal intake;
• governed by a separate policy;
• activated only for a bounded case, source, time window, and purpose;
• approved by two distinct authorized people where required;
• stored separately;
• protected by separately approved encryption keys and access roles;
• bound to region and retention decisions;
• subject to legal hold and deletion rules; and
• fully auditable.

Accepting the Briard KAIDAN add-on agreement does not enable restricted capture.

Evidence classifications

Observed fact

KAIDAN directly received or produced the referenced event or receipt. This says nothing beyond the fields actually observed.

Source assertion

An external system made the statement. KAIDAN preserves who said it and does not adopt the source’s conclusion as fact.

Detector inference

A rule, correlation, or model inferred a possibility. Preserve the inputs, version, confidence, and limitations.

Reviewer conclusion

A named authorized human evaluated evidence and made a bounded decision. Preserve contrary evidence and open gaps.

Missing evidence

Missing evidence remains unknown. It is not automatically:

• proof that nothing occurred;
• proof a control failed;
• proof a user acted maliciously;
• permission to infer prompt content; or
• permission to widen a connector without approval.

The investigation should show the expected receipt, time range, likely reason, owner, next action, and effect on confidence.

Tenant isolation

Every request must be bound to the authenticated KAIDAN identity and server-validated tenant. Evidence, cases, searches, exports, and connector state are tenant-scoped.

Test isolation during deployment and after material changes. A user from one tenant must not be able to retrieve identifiers, counts, timing, or content from another.

Credentials

• Create a dedicated least-privilege service identity per source where practical.
• Keep credentials in the customer-approved secret manager.
• Pass only a secret reference to deployment configuration.
• Deny credentials to the browser and general relay when an isolated adapter can hold them.
• Rotate and revoke on a schedule and after suspected exposure.
• Test that the retired credential no longer works.
• Never put secrets in chat, email, support tickets, source control, screenshots, command arguments, plans, or evidence exports.

Network and deployment

Use default-deny network policy. Permit only reviewed identity, database, object storage, source, trust, and operational endpoints. Pin immutable images and signed artifacts. Require TLS and mutual TLS where specified. Treat a cloud or Kubernetes control as unproven until the customer deployment supplies its own validation receipt.

Custody and integrity

KAIDAN preserves append-only evidence relationships and produces verification material. Custody verification can show that the package matches the retained digests and signatures. It does not by itself prove:

• the external source was truthful;
• the source had complete visibility;
• a person had a particular intent;
• an event caused another event;
• a court will admit the evidence;
• an external timestamp or notary was used unless its receipt exists; or
• an independent reviewer approved the package.

Retention, deletion, and legal hold

The customer must decide retention by evidence class, contract, incident policy, and applicable law. Legal hold can block ordinary deletion. Deletion or expiration must not falsify the custody record; preserve the authorized disposition receipt and the fact that an object is no longer retained.

Restricted content requires its own shorter, explicit retention unless counsel or policy requires otherwise.

Response and enforcement

KAIDAN may preserve a proposed, approved, executed, source-reported, or independently verified response state. These are not interchangeable.

KAIDAN observes and preserves evidence. It must not silently become an inline enforcement control for Briard-AI. A customer-controlled system may act through a separately approved workflow, but the customer owns the authorization, blast radius, rollback, and validation.

Assurance statements

Use these phrases:

• “The signed compatibility package is installed.”
• “This self-hosted source test passed.”
• “This provider field receipt is present.”
• “The customer deployment validation passed.”
• “An external trust receipt is present.”
• “An independent reviewer approved this conclusion.”

Do not shorten those different facts into “certified,” “fully covered,” or “proven secure.”

Report a concern

Contact security@briard-ai.app. Include identifiers, timestamps, versions, and digests. Do not include credentials or sensitive content.