Security
Security is architectural. Not a checkbox.
FlowCounsel™ is designed for the legal-AI threat environment that exists today: hallucinated citations reaching courts, privilege exposure through unbounded workflows, software producing legal effect without human approval, and firms trapped inside collapsed vendor stacks. Paper certifications document past audits. Architectural primitives prevent the next class of breach.
Architectural security·Supervised by design·Threat-aware design·Firm-scoped
The threat moment
The legal-AI threat environment in 2026.
Recent cases and incidents define what a defensible legal AI system has to be designed for. None of this is theoretical.
Sanctions
Hallucinated citations leaving the firm.
A growing pattern in sanctioned filings: model output reached the court because the workflow had no enforced approval transition between draft and filed. The architectural fix is not better prompts; it is review state as a typed transition on the artifact.
Privilege
AI conversations are not automatically privileged.
United States v. Heppner (S.D.N.Y., Feb. 2026, Rakoff, J.) held that exchanges with a consumer AI chatbot were not protected by attorney-client privilege or the work-product doctrine, in part because the vendor's policy allowed disclosure and the user was not acting at counsel's direction. The architectural answer is the inverse pattern: enterprise platform with a training boundary, firm scoping, attorney supervision built into the workflow, not bolted on.
Algorithmic execution
Software producing legal effect without human approval.
Algorithmic-contracting precedent from international courts is forcing the question of who bears responsibility when software acts. A system whose architecture allows externally-effective output without an approval transition pushes that responsibility onto the firm whose name attaches to the output.
Vendor collapse
Firm work trapped inside a single-provider stack.
Recent legal-tech collapses have left firms stranded inside vendor-controlled data models. The architectural fix is to keep the matter record, approval state, and firm intelligence portable above the inference layer, so a model or provider change does not require a data migration.
Architectural security primitives
Security as a property of the system, not a layer above it.
The primitives below are the architectural surfaces a firm can inspect, query, and verify. They map directly to the architecture page; here they are viewed through the security lens.
Judgment-gated
Attorney review is the control boundary.
Specialists prepare. Attorneys decide what leaves draft state or moves into external effect. Final state changes are gated by a non-bypassable, reviewer-identity-bound approval transition, not by a UI flag.
Auditability
Runs, edits, and approvals stay visible.
Every workflow run carries its context manifest, the model and tool calls made, the verifier results checked, and the produced artifact. The audit trail is queryable, replayable, and exportable. Not a CSV of event names.
Firm scoping
Firm work stays firm-scoped.
Retrieval is bounded by firm, client, matter, jurisdiction, and specialist context. Patterns learned at one firm stay at that firm. No cross-firm pooling, no cross-customer blending.
Controls
AI access is scoped by workflow and role.
Capabilities, review expectations, and approval authority are scoped by surface, role, and workflow. Roles and final authority live in the data model, not in user discretion.
Refuse-when-unsure
The system declines when context is insufficient.
Every run records a sufficiency state of sufficient, needs-information, or inconclusive. The system is permitted to decline rather than produce a confident wrong answer.
Encryption
TLS 1.3 in transit. AES-256 at rest.
Encryption uses TLS 1.3 in transit and AES-256 at rest via AWS-managed keys. Infrastructure secrets and service credentials are managed through provider-backed controls (AWS KMS, IAM, CloudTrail), not embedded in application code.
Diagram · Threat → architectural mitigation
Each threat surfaced earlier on this page has a named architectural primitive that addresses it. The pairs are designed-in, not bolted-on.
AI-specific security
The threat surface that generic SaaS security pages skip.
Encryption, subprocessor lists, and provider IAM cover the SaaS-era threat surface. They do not cover the AI-era threat surface. Each pattern below is addressed by a named architectural primitive, not by a policy hope.
Threat
Prompt injection
Architectural mitigation
Bounded specialist contracts and separation of system instructions from user content. A specialist runs against a typed contract (declared inputs, declared outputs, declared invariants) that does not yield to in-content instructions to act outside scope.
Threat
Output fabrication (citations and quotes)
Architectural mitigation
Citation Ledger requires structured source records (URI, version, content hash, passage span, last-verified timestamp) for legal-fact assertions. Verifier checks compare claimed citations against retrieved sources. Refuse-when-unsure declines rather than producing a confident wrong answer.
Threat
Training-data leakage to vendor model
Architectural mitigation
Contractual no-training boundary with the inference provider (AWS Bedrock). No fine-tuning of foundation models from customer inputs. FirmIQ™ patterns are workspace-scoped at the application layer and never leave the firm boundary.
Threat
Model context manipulation
Architectural mitigation
Context Manifest is intended as a durable, versioned record of what was loaded, why each record was eligible, what was excluded, and which assembly policy version was in force. Runtime context assembly is bounded by structured policy, not by ad-hoc retrieval.
Threat
Specialist boundary violations
Architectural mitigation
Each specialist declares its inputs, outputs, invariants, review behavior, and failure model. A drafting specialist cannot escape into legal-advice territory because the boundary is part of the contract, not a user-discretion check. Refuse-when-unsure surfaces a sufficiency state of inconclusive rather than confabulating.
Threat
Autonomous tool-chain execution
Architectural mitigation
Tool and connector access is treated as an authority boundary. High-risk actions are classified by effect (read-only, draft-only, internal write, external send, export, financial, court/government) and externally-effective chains require approval state, workflow records, and per-call audit rather than model discretion.
What we will not do
Anti-promises that hold at the data model, not in user behavior.
The patterns excluded by design are the patterns most often conflated with "secure AI" in vendor pitches. Each is architectural, not policy.
No cross-firm pattern pooling.
Patterns learned at one firm stay at that firm. Every FirmIQ™ retrieval and write is scoped by workspace at the application layer. No vendor-side aggregation, no "the platform gets smarter from all our customers."
No silent fine-tuning from customer inputs.
Customer inputs routed through model execution are not used to train underlying foundation models. The training boundary is contractual with the inference provider and architectural in how data is routed.
No autonomous external effects.
No system action produces an externally-effective output (sent, filed, signed, delivered) without an explicit, reviewer-identity-bound approval transition. The data model enforces this, not the UI.
No raw keystroke surveillance as default capture.
Learning signal is captured at document-level diff granularity, not character-level telemetry. The signal-to-burden ratio is poor and the privacy posture conflicts with the confidentiality obligations under ABA Model Rule 1.6.
No opaque model context.
Every retrieval records what was loaded, why each record was eligible, what was deliberately excluded, and which assembly policy version was in force. "Personalization" that cannot be inspected is not personalization; it is leakage.
No certifications we have not earned.
FlowCounsel does not hold SOC 2 Type II, ISO/IEC 42001:2023, or completed external penetration testing today. We do not claim them until they are complete. Security is delivered through architectural primitives, not through periodic audits of past behavior.
Data handling
Data handling, inference, and provider posture.
Current details for model execution, retention, hosting, and provider portability.
Multi-model orchestration
AWS Bedrock as the inference layer.
Inference runs through AWS Bedrock with task-appropriate model selection. Different specialists run against different models. The matter record, approval state machine, audit trail, and FirmIQ™ memory live above the inference layer and stay portable as orchestration evolves.
Training boundary
Customer inputs are not used for model training.
Customer inputs routed through Bedrock model execution are not used to train underlying foundation models. The training boundary is contractual with the inference provider and architectural in how data is routed.
Hosting region
US cloud infrastructure.
Application and workflow infrastructure run in US cloud regions, with model requests routed through FlowCounsel™ services rather than directly from the browser. Region pinning and provider IAM are enforced through AWS account-level controls.
Provider portability
Inference is the swappable layer.
The firm record (matter state, approvals, audit, FirmIQ™ patterns) is architecturally portable. A model swap inside Bedrock is operational, not architectural; an inference-provider change does not require a data migration.
Retention and legal holds
Firm-defined retention.
FlowCounsel is designed to support firm-defined retention and legal-hold requirements rather than impose a one-size-fits-all retention rule.
Authentication
Identity and session through Clerk.
Authentication runs through Clerk with workspace and organization management, role-based controls, and multi-factor authentication available. Session state and credential storage are provider-managed; credentials are not embedded in application code.
Workspace isolation
Firm data is keyed to workspace scope.
Every stored object and metadata record carries a workspace identifier. Every query path filters by workspace at the application and data layers. FirmIQ™ retrievals are workspace-bounded. This is logical isolation on shared infrastructure (the industry-standard SaaS pattern); dedicated single-tenant deployment is available on enterprise contract terms.
Recovery and testing
Backup, recovery, and penetration testing.
Backup, logging, and recovery controls are part of the production environment. Additional operational details are available during procurement review. External penetration testing is not complete yet, and not claimed until it is.
Subprocessors
Infrastructure and service providers.
Complete list of providers that process customer data or support product operations. Updated as the production environment changes.
Evaluation questions
Architectural security is evaluable, not declarative.
Architectural questions a general counsel or IT lead can use to evaluate any legal-AI vendor’s security posture, including FlowCounsel’s. The questions surface design discipline, not feature lists.
Ask
“How is the context manifest structured for a given run? What fields are recorded, what makes a record eligible, and what gets excluded?”
What it surfaces
Bounded retrieval design. The manifest is intended as a durable structured record (loaded set, eligibility basis, exclusions, assembly policy version). Vendors describing retrieval as a "context cache" or "personalization" without inspectable structure fail this question.
Ask
“How does the data model enforce approval transitions? Walk me through what stops externally-effective work from leaving the system without a state change.”
What it surfaces
Approval-gated execution as architecture, not policy. If the enforcement is a UI flag rather than a typed transition on the artifact, the protection is theatrical.
Ask
“How are reversed approvals handled? What happens to downstream work product produced under the basis that was just reversed?”
What it surfaces
Recall is intended as a first-class event. The architecture should be able to identify and re-flag affected artifacts. "Recall silence" is the failure mode where reversal is recorded but operationally invisible.
Ask
“How are runtime safety constraints declared, owned, and enforced? Are they registered with severity tiers and named enforcement layers?”
What it surfaces
Invariant registry design. Safety constraints expressed as a registered, owned contract (with severity and enforcement layer per constraint) rather than as scattered policy hopes.
Ask
“How is run replay designed? What does it take to reconstruct what the system saw, called, and produced on a specific run?”
What it surfaces
Replayability design. A firm should be able to reconstruct the run inputs, context manifest, model and tool calls, verifier results, and produced artifact. Without replay-by-design, there is no defensible audit.
FAQ
Common infrastructure and security questions.
Firm data includes records the workspace places into the system: uploads, intake or matter context, review history, approved work product, communications, and related operational data. All firm data is keyed to workspace scope.
Firm data rights
Export, deletion, and audit access.
The firm owns its firm data. The architecture is designed so a firm can export, delete, and audit what the system holds about its work.
Export
Firm data export.
Matter records, work product, approval history, audit trail, and FirmIQ™ patterns can be exported on firm request. Export formats and timelines confirmed during procurement.
Deletion
Firm data deletion.
A firm can request deletion of firm data on termination. Retention obligations under client legal-hold requirements take precedence; deletion confirmed once holds are cleared.
Audit access
Firm audit visibility.
Workflow runs, approval transitions, and lineage are queryable as part of the product surface. Procurement review covers access to infrastructure-layer audit (AWS CloudTrail).
Vulnerability disclosure
Responsible disclosure pathway.
Security researchers can report suspected vulnerabilities to security@flowlegalpartners.com. A published security policy is available at /.well-known/security.txt.
Procurement
Security review and procurement contact.
Security inquiries can be sent to security@flowlegalpartners.com. Privacy and DPA requests can be sent to privacy@flowlegalpartners.com.
Read next
Where security connects to the rest of the system.
The architectural thesis these primitives implement, the published research that grounds them, and the consulting program for firms maturing their own AI governance.