Briard Alert & Response Console (BARC) security and data boundaries

This page explains what BARC 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. BARC is the security and incident-forensics add-on.

BARC 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 BARC add-on agreement does not enable restricted capture.

The case-specific choices are Check content and show findings (private_content_analysis) and Read original evidence (case_forensics). The first examines approved content inside the customer's environment and keeps findings and receipts, without retaining originals as case evidence. The second holds only approved original items for an explicitly chosen review period. The same case then guides an authorized reviewer through choosing exact items, their purpose and retention, and the separate two-person approval to keep them. Asking for originals does not grant the requester a new role or content-reading rights.

BARC prepares each exact-item request from an immutable collection receipt. After the required approvals, a source-bound worker checks current authority, verifies the encrypted copy and exact bytes, and transfers them into the approved evidence store. Failed transfers remain visible and need a permitted retry or repair; an approval or collector report alone is not proof that an original is ready to open. Eligible readers provide a reason for each audited access. Normal event telemetry, Briard governance records, and routine evidence packages remain free of original content.

Collection expiry, the temporary review-holding period, and evidence retention are different decisions. Temporary cleanup needs fresh permission checking the exact retained copy, legal holds and active preservation. Historical requests without explicit holding-period consent gain no invented deletion authority. Cleanup reports remain source assertions. Neither choice enables an unconfigured source or changes metadata-only normal intake. Read Review private evidence in a case for the guided request, approval, preparation, recovery and evidence-review path.

Evidence classifications

Observed fact

BARC 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. BARC 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 BARC 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

BARC 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

Briard's production default is 365 days for platform evidence records and immutable evidence-package objects. Legal hold can block ordinary deletion beyond the otherwise eligible date. Deletion or expiration must not falsify the custody record; preserve the authorized disposition receipt and the fact that an object is no longer retained.

Customer-controlled external destinations have separate retention and deletion controls. Existing COMPLIANCE-locked objects cannot have their retain-until date shortened.

Restricted content requires its own explicit retention and separate authorization and cannot exceed 365 days.

Response and enforcement

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

BARC 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.