A security page that asks you to trust the vendor has already failed its job. Driftless is built to operate customer workflows, use AI, coordinate agents, connect systems, handle business state, perform authorized actions, preserve evidence, manage economic exposure, and in some deployments operate close to sensitive or regulated information. That gives the security model a harder job than protecting a passive dashboard.
The system must answer a more demanding set of questions: Who can reach what? Who can authorize what? Which machine identity is acting? Which tenant owns the data? What purpose allows the action? What economic authority exists? What scarce resources may the operation consume? What happens when permission changes? What proof remains after the action? Can the customer detect, contain, recover, export, and leave?
Driftless is Density6's founding Vertical Intelligence Product. Security therefore has to govern more than a model endpoint. The governed object can include an operational ontology, current and historical state, authority, policy, capabilities, workflows and missions, evidence, economics, deployment, learning, and verification. Weakness in any one of those surfaces can become an operating risk even when the model itself is behaving exactly as designed.
This page is written for security leaders, enterprise architects, risk teams, privacy officers, compliance teams, procurement reviewers, government security personnel, and technical buyers who expect the details to survive scrutiny. We are telling you where to look so you can make your own decision from the evidence.
Security cannot be stronger than the architecture description it is protecting. If the production system moved but the security plan still describes the old environment, the document is not evidence of the current system. It is history.
Driftless therefore treats current architecture, data flow, identity, privileges, subprocessors, deployment topology, commercial authority, and control ownership as facts that must be re-derived from the operating system and supporting evidence rather than repeated from an old diagram. A skeptical reviewer should be able to ask:
What is deployed now?
Where does customer data go now?
Which identities exist now?
Which roles can bypass normal application controls?
Which systems hold secrets or keys?
Which components can make external changes?
Which components can spend scarce resources or create economic exposure?
Which controls protect those components?
Which evidence shows the controls are operating?
Which exceptions remain open?
What changed since the last review?
Security begins by refusing to protect an imaginary system.
A conventional AI security review can stop too early at prompt injection, model provider terms, and tool permissions. Driftless has to defend a larger operating object.
A serious review should consider whether an attacker, compromised identity, faulty integration, stale policy, malicious prompt, bad model output, or internal error could corrupt or misuse:
the ontology that defines what operational objects exist;
the state that determines what the system believes is true;
the authority graph that determines who or what may act;
the policy and constraint layer that determines what is admissible;
the capability registry that determines what can technically execute;
the workflow or mission definition that determines how objectives move;
the evidence chain that is later used to prove what happened;
the economic-authority boundary that determines what scarce resources may be risked;
the deployment state that determines where work may run;
the learning system that can change future behavior;
the verifier that decides whether a claimed result actually matured.
The model is one dependency inside that system. Securing only the model would leave the operating reality around it exposed.
A multi-tenant platform should not depend on every developer remembering to add the correct tenant filter to every query forever. Driftless' enterprise security architecture is designed to make the tenant boundary a first-class control problem. Database identities, application roles, service roles, auditors, migration paths, break-glass access, row-level protections, connection policy, immutable ledgers, storage boundaries, caches, indexes, search surfaces, background workers, AI retrieval paths, commercial objects, and evidence stores all matter.
A skeptical security team should expect adversarial testing of this boundary. We want tests that attempt to cross tenants using hostile queries, malformed identifiers, elevated paths, background jobs, cached state, stale objects, search indexes, API misuse, and privileged operations. A control should be able to fail a test when the boundary is broken.
That last part matters. If the test suite is constructed so the tenant-isolation gate can never turn red, the gate is not proving isolation. A serious control system includes planted failure cases because negative proof is part of trust.
A privileged account changes the meaning of almost every application-level control beneath it. Driftless separates ordinary application behavior from migration authority, administrative authority, audit authority, service identities, machine identities, and break-glass access. The purpose is to reduce the number of paths where a routine application request can inherit powers intended only for controlled operations.
For an enterprise reviewer, useful questions include:
Which identities can modify production schema?
Which identities can bypass tenant controls?
Which identities can read cross-tenant data?
Which identities can access secrets?
Which identities can modify audit evidence?
Which identities can approve or mint authority?
Which identities can modify commercial catalog state or settlement authority?
How are service identities rotated and reviewed?
How are human privileged accounts governed?
What evidence is produced when break-glass access is used?
How are dormant privileges removed?
A role name does not prove least privilege. The effective permissions do.
An autonomous agent should not borrow the vague authority of "the application." Driftless is designed to bind work to identifiable human, service, workload, and agent subjects. Enterprise deployments can integrate with identity systems through SAML/OIDC and provision or deprovision users through SCIM where appropriate. MFA, access reviews, privileged-access controls, machine identities, service identities, device or workload posture, and tenant policy can participate in the effective authority decision.
The operating principle is that delegation can narrow authority. It cannot silently widen it.
If a person has authority to approve a campaign but not export a sensitive dataset, an agent acting for that person should not gain export authority merely because the model can call the tool. If a workload has permission to send approved messages but not change the consent policy that governs those messages, the action system should preserve that distinction.
Capability and authority belong in separate columns.
Operational permission is not permission to consume unlimited resources or accept unlimited financial exposure. Autonomous systems can create damage through waste as easily as through a forbidden action.
Driftless therefore separates action authority from economic authority. A workload may be permitted to run while still being bounded by a maximum provider cost, concurrency limit, retry budget, communication spend, human-support burden, infrastructure reservation, or other risk envelope.
Fair Throughput & Utilization™ governs this production boundary. FTU can help determine whether execution may happen, how much scarce resource it may consume, which production path should be used, how much retry or repair effort is admissible, and whether the safe response is to route down, queue, defer, ask, pause, or stop.
For security review, that means an agent cannot justify unlimited resource consumption by pointing to a valid tool permission. Capability, authority, and economic authority are related. They are not interchangeable.
A common enterprise AI architecture makes one dangerous leap: the model can see a tool, so the model is allowed to use the tool. Driftless is designed to put an action boundary between intelligence and execution.
The model can propose. The operating system checks whether the action is permissible under the identity, objective, delegation, tenant policy, purpose, markings, budget, environment, approval state, tool lease, economic authority, and other controls that apply.
The result may be execution. It may also be approval required, narrowed action, deterministic fallback, lower-cost route, abstention, pause, escalation, or refusal.
For security review, ask us to demonstrate the denied path as well as the successful path. A system that can show what it refuses is easier to evaluate than one that only demonstrates what it can do.
Vertical Intelligence can package reusable operating knowledge and mission capability. A Mission Kit may contain ontology, connectors, data contracts, actions, policies, workflows, dashboards, measures, deployment assumptions, and verification logic. Installing such a package should not silently grant it production authority.
The presence of a capability says that the system knows how to perform the work. Deployment, tenant policy, identity, purpose, data classification, approvals, economic authority, and local contract state still determine whether that capability may act in this environment for this customer now.
This distinction becomes more important as reusable Vertical Intelligence grows. Distribution can scale faster than authority should.
Security teams often receive logs that show activity without enough context to establish why the activity was allowed. Driftless is designed so consequential actions can be associated with a richer receipt. Depending on the action and disclosure boundary, the evidence can identify the objective, actor, authority, policy, relevant source state, action, target system, execution state, production cost, commercial contract, result, settlement state, and later observation.
This supports several jobs at once. Operations can understand what happened. Security can investigate misuse or abnormal behavior. Compliance can connect an action to a control or obligation. Finance can inspect production economics and settlement. Customers can receive proof appropriate to the transaction. Learning systems can reconcile the result without rewriting the original record.
A log line saying success=true is not enough for every consequential action.
An audit trail that the same privileged path can casually rewrite is weaker than it looks. Driftless' security program treats important ledgers, consent records, AI receipts, call-compliance records, administrative actions, commercial contracts, financial settlement events, and security events as evidence that requires stronger integrity properties than ordinary application records.
The architecture favors append-only or compensating-event patterns where the history matters. A correction adds a new event rather than erasing the event that created the need for the correction.
That is especially important in billing, consent, authority, security investigations, and outcome attribution. The question is not merely whether the current state is correct. The organization may need to know how it became correct.
A technical system capable of creating a charge is not therefore authorized to create the charge.
Driftless separates the commercial contract, economic authority, execution, verification, and commercial settlement planes. A model call, API success, workflow start, agent action, or Stripe object does not independently create commercial authority. The contract defines the settlement event. Evidence establishes whether the required state occurred. Verification determines whether that state matured under the contract. Only then can the commercial settlement plane determine what became payable.
This is also why the browser is not allowed to declare price truth. Customer-facing commercial links carry a canonical offer identifier. The server-side Density6 commercial catalog resolves the product, scenario, price, billing type, authority, settlement mode, Stripe lookup key where applicable, and contract requirement.
A browser-supplied dollar amount is not commercial authority.
Saying "data is encrypted" answers too little. A useful data and cryptography review should also examine classification, key custody, secrets, retention, legal hold, deletion, cryptographic erasure where appropriate, backup behavior, residency, replication, indexing, AI-data boundaries, restore procedures, and access paths.
Driftless is designed so data policy can follow the information across the systems that use it rather than stopping at the primary database. A skeptical reviewer should ask where copies appear.
Search indexes matter. Caches matter. Backups matter. Logs matter. Prompt and retrieval paths matter. Exports matter. Offline stores matter. Training and evaluation corpora matter.
A strong deletion policy that ignores the index is not a strong deletion policy.
Operational access and learning authority are different permissions. A customer may authorize Driftless to use information to complete a task without authorizing Density6 to retain that information forever, move it to another region, expose it to another tenant, use it to train a model, or repurpose it for unrelated analysis.
Driftless is designed to consider tenant boundary, classification, purpose, provenance, retention, residency, policy, and learning authority when determining whether information may enter a model or learning path. The security team should ask the question directly:
If the platform may read this record to complete the authorized workflow, what prevents that operational permission from silently becoming training permission?
That is the right question.
Reality-Reconciled Learning compares prior machine judgment with later verified reality so future behavior can improve. That learning path creates its own security boundary.
A later outcome may justify changing a prediction model, routing policy, estimator, workflow strategy, or recovery path. It does not automatically justify changing signed policy, customer authority, an immutable historical fact, a settled commercial event, a retention obligation, or a hard security boundary.
Candidate changes should be attributable to evidence, evaluated against historical cases, tested under controlled conditions, shadowed where appropriate, promoted under explicit authority, and reversible. A trainer should not promote itself. A verifier should not certify itself. A model should not rewrite the evidence that will later be used to judge the model.
Adaptive Vertical Intelligence is valuable precisely because it can learn from real operation. That makes the governance of learning part of the security model rather than an afterthought.
Frontier models change. Pricing changes. Terms change. Availability changes. Customer policy changes. Some workloads may prohibit an external model entirely.
Driftless separates the operating state of the business from the model selected for a particular task. The customer's operational ontology, authority, workflows, history, evidence, receipts, approvals, commercial state, business state, and mission continuity do not have to disappear when the provider changes.
A deployment may use a provider model, a customer-provided key, a local or customer-controlled model, Driftless' model infrastructure, or a deterministic path where generative AI is not appropriate.
A security review should therefore separate two questions: What model is used for this workload? What would break if that model were removed tomorrow?
The second answer should be much smaller than "the company stops operating."
Some organizations already have approved model accounts, negotiated provider terms, regional requirements, or internal key-management processes. Driftless supports BYOK patterns so a customer can supply supported model credentials without making the provider the owner of the business operating state.
The canonical Density6 markup on supported BYOK model-provider spend is 0%. Commercial transparency does not weaken the security requirement. The key should still be protected, scoped, audited, and used only through the governed path intended for it. BYOK means the customer can control a model credential. It should not mean the credential becomes ambient authority inside the application.
Application security is not finished when the code passes a unit test. Driftless' secure operations plane includes secure development practices, dependency and software-supply-chain controls, vulnerability management, production telemetry, incident response, backup and disaster recovery, release governance, and evidence generation.
For buyers evaluating the software-development lifecycle, useful review areas include:
source-control governance;
branch and release protections;
code review;
dependency inventory;
vulnerability scanning;
secret detection;
artifact integrity;
build provenance;
release authorization;
environment separation;
patch policy;
vulnerability intake and triage;
incident escalation;
rollback and kill mechanisms;
evidence retention.
The correct depth depends on the engagement. We do not expect a public website to expose internal attack surfaces in detail. NDA review can go deeper where the customer risk justifies it.
A strong security architecture can still fail during release. Wrong configuration. Wrong environment. Wrong secret. Wrong policy version. Wrong migration. Wrong model. Wrong feature flag. Wrong identity. Wrong rollback path.
Driftless' release model is designed to make release a governed state transition with canary, rollback, kill, proof, and recovery capabilities rather than a blind act of copying code into production. The same principle applies to AI behavior changes. Candidate intelligence should be evaluated and promoted under governance rather than gaining production authority because a model provider shipped a new version.
Deployment is an action. It deserves evidence.
A control can be strong Monday and weakened by a newly disclosed vulnerability Wednesday. Continuous compliance means the system should be able to connect new vulnerability information to the controls, systems, vendors, or evidence that depend on the affected component.
The purpose is not to generate panic every time a CVE appears. The purpose is to stop stale evidence from silently remaining green when the dependency moved. A security program should be able to answer: Which production assets are affected? Which controls depend on them? Which customer commitments are implicated? What is the remediation status? Does the risk require containment, configuration change, patching, compensating control, or customer communication? What evidence closes the finding?
That chain is more useful than a monthly spreadsheet exported from a scanner.
Large organizations already have a security operating model. Driftless should not demand that the customer's security team abandon it to see what Driftless is doing.
Enterprise deployments can provide customer-relevant audit and security telemetry, including SIEM export or integration paths where appropriate to the contract and technical boundary. The goal is to make important Driftless events visible to the systems and teams already responsible for detection, investigation, and response.
A customer should know what can be exported, at what granularity, under which retention policy, with which identifiers, and with which privacy protections.
Every vendor says it has incident response. Skeptical buyers should ask what the statement means operationally.
Who detects the incident? Who owns the response? What severity model applies? What customer notification obligations exist? What evidence is preserved? How is access contained? How are keys, credentials, or sessions revoked? How are affected services isolated? What is the recovery path? What is the post-incident review process? How are corrective actions tracked? Which commitments belong in the contract?
The exact answers depend on the service level and deployment model. Those answers should be known before the incident, not invented during one.
A backup is not recovery. A disaster-recovery document is not a recovered service.
A continuity claim should connect to actual recovery objectives, backup integrity, restore testing, dependency recovery, failover behavior, communications, and evidence. Driftless also has to preserve the state of long-running work. Agent tasks, approvals, workflows, result contracts, pending settlements, deployment state, and operational history should not vanish because a worker restarted or a provider timed out.
For a skeptical buyer, ask us to distinguish data backup, service recovery, workflow recovery, agent-work recovery, commercial-state recovery, customer communication, and full business continuity. They are related. They are not interchangeable.
A contact center creates a specific class of risk because the system reaches outside the enterprise and acts on people. A mature operating path needs more than call quality and throughput. It needs to know why the communication is allowed.
Driftless' contact-center governance is designed around controls for consent, revocation, Do Not Call status, calling windows, jurisdiction, recording requirements, artificial or AI voice governance, required disclosure, payment handling, carrier trust, number reputation, retention, deletion, and human escalation where those requirements apply.
The security property is broader than "the call was encrypted." A consequential outbound action should know the permission basis before it occurs. That principle gives legal, compliance, security, and operations teams a shared object to inspect.
Contact-center payment collection creates additional risk because voice, recordings, transcripts, agent desktops, logs, and analytics can accidentally become storage locations for card data. Driftless' payment-related security design is intended to separate governed payment operations from conversational or recording surfaces so sensitive authentication data does not become a casual byproduct of the call.
The specific PCI scope depends on the payment architecture and customer deployment. A skeptical buyer should ask us to identify that scope rather than accepting a generic "PCI-compliant" phrase. Scope is part of the proof.
Privacy review should be able to identify:
what data enters the system;
why it is needed;
who controls it;
who can access it;
where it is stored;
where it is processed;
how long it is retained;
what subprocessors participate;
how deletion works;
how legal hold affects deletion;
whether data can cross regions;
whether data can enter AI or learning paths;
how exports work;
what happens at contract termination.
The privacy policy can describe the company position. The operating system must implement the actual boundary. When those disagree, the operating behavior is the risk.
We do not want separate fictional implementations called "the SOC 2 system," "the HIPAA system," "the ISO system," and "the government system." A real control should exist once in the operating environment. The evidence produced by that control can then be mapped to the frameworks, contracts, and assurance obligations for which it is relevant.
Strong identity governance can support several frameworks. So can tenant isolation, incident response, encryption, change management, vulnerability management, evidence integrity, continuity, access review, and data governance.
The mapping is not the control. The audit is not the control. The certificate is not the control. The operating mechanism is the control. Evidence from that mechanism is what makes the assurance claim defensible.
The Trust Center should expose the current state of applicable assurance work rather than turning a once-correct badge into permanent website decoration. Depending on the current certified and contracted scope, the enterprise assurance program can include SOC 2 reporting, ISO/IEC 27001 certification, ISO/IEC 27701 privacy management, ISO/IEC 42001 AI management, PCI DSS validation, HIPAA and BAA readiness where applicable, HITRUST where justified, GLBA controls, FERPA controls, CJIS and GovRAMP paths, CMMC and NIST requirements where FCI or CUI applies, and FedRAMP work where the actual offering and federal use case require it.
Those labels are not interchangeable. SOC 2 is an attestation/reporting framework, not an ISO-style certification. HIPAA applicability depends on the actual relationship and data handled. CMMC depends on the contract and information boundary. FedRAMP is an authorization path tied to a specific cloud offering and government use, not a general adjective for secure software.
Government or classified use requires the actual authorization and accreditation required by the agency, contract, data, environment, and mission. The current status should be stated precisely.
Sovereignty can mean dedicated infrastructure, customer-controlled deployment, local or edge operation, disconnected operation, air-gapped environments, customer-controlled credentials, customer-controlled storage, private networking, or other contractually defined changes to where authority and custody sit.
Those choices can reduce some dependencies and introduce others. A customer-controlled environment may reduce reliance on a shared SaaS plane while increasing the customer's responsibility for hardware custody, local identity, network configuration, physical security, patching, backup, key management, and local incident response.
A disconnected environment can reduce some network exposure while making synchronization, revocation, evidence transfer, update distribution, and time integrity harder.
A Sovereign Vertical Intelligence Platform is therefore not a marketing badge that means "more secure." It is a deployment and responsibility class whose exact boundary must be written and tested. Sovereignty is valuable when it places responsibility where the customer and mission require it.
Transparency has a security boundary. We can provide customers and reviewers with appropriate reports, certificates, architecture summaries, data-flow documentation, control descriptions, penetration-test summaries, continuity evidence, incident commitments, privacy documents, AI-governance materials, accessibility evidence, customer-relevant audit data, and other proof required for the relationship.
We do not publish internal exploit playbooks, scoring models, command classifiers, adversarial test logic, isolation implementation details, key-management orchestration, protected evidence-graph internals, security automation logic, or other material whose disclosure would increase attackability or surrender protected technical advantage.
A mature Trust Center should help the buyer evaluate the control without giving an attacker a manual for bypassing it.
A vendor cannot ask enterprise customers to perform rigorous third-party risk review while ignoring its own dependencies. Driftless' security program includes vendor and subprocessor governance, contract tracking, data-flow awareness, vulnerability impact, evidence collection, and customer-facing subprocessor disclosure where appropriate.
The security team should ask which dependencies can access customer data, which dependencies can affect availability, which dependencies participate in AI, which dependencies are required for communications, and what happens if a dependency fails or becomes unacceptable.
Replaceability is a security property when the alternative is operational captivity.
Vendor lock-in is usually discussed as a commercial issue. It can become a security and continuity issue when a customer cannot leave an unsafe, unaffordable, unavailable, or noncompliant provider without losing its operating history.
Driftless' sovereign-exit design is intended to preserve supported customer-owned business state, workflows, evidence, receipts, configuration, and audit records in an exportable form and validate that the export can be reconstituted. A skeptical buyer should ask what remains vendor-specific, what can be exported, which dependencies must be replaced, how secrets are handled at termination, how data is deleted, and how the reconstitution drill is performed.
Exit should be tested before it becomes an emergency.
A strong review starts with the exact proposed workload. Define the objective. Identify the users and machine identities. Map the systems. Classify the data. Define the authority. Define the economic authority. Identify the external actions. Identify the required approvals. Identify the legal and contractual obligations. Establish the evidence needed. Establish the rollback and stop conditions. Confirm continuity requirements. Confirm the current assurance scope. Run adversarial and negative tests. Start with the smallest authority that can produce useful evidence.
Then watch the system operate.
A successful pilot is not "the AI generated good output." A successful pilot shows that the operating result occurred inside the agreed authority, economic, and security boundary; that the evidence exists; that the failure path works; that the settlement path cannot outrun verification; and that the customer can stop or recover when required.
A security review is useful only if "no" remains possible. We may recommend delaying or narrowing a deployment when the required identity integration is not ready, the tenant boundary cannot be proven for the requested architecture, the data classification is unresolved, a required subprocessor is unacceptable, the customer needs an accreditation the actual offering does not yet hold, the legal basis for a communication workflow is unclear, the requested AI authority is broader than the organization can govern, the requested economic authority cannot be bounded responsibly, the recovery requirement exceeds the proposed topology, or the evidence needed to prove the result does not exist.
Those are not sales failures. They are boundary findings. The right response is to close the finding, change the scope, or decline the workload.
Tell us what you are trying to evaluate.
If you are a CISO, tell us the deployment topology, data class, identity requirements, integration surface, SIEM expectations, criticality, and control frameworks that matter.
If you are procurement, tell us the questionnaire, insurance requirements, SLA terms, accessibility obligations, privacy documents, subprocessor requirements, commercial object, and exit provisions you need.
If you are legal or privacy, tell us the data, jurisdictions, retention, contact-center activity, AI use, recording, payment, outcome attribution, or other regulated behavior in scope.
If you are a government or prime contractor, tell us the agency, mission, information category, contract requirement, hosting boundary, required authorization, and whether FCI, CUI, CJIS data, PHI, payment data, student records, or another regulated category is involved.
We will map the review to the actual workload rather than hand you every document we possess and call that transparency.
Run the security review against one real proposed workload. That gives both teams a concrete boundary to evaluate and exposes missing controls before a broad deployment makes them expensive.
[REQUEST SECURITY & TRUST REVIEW]
The Free Gate tier is free, permanently, and you do not need a credit card to start. The Free Gate is $0 forever. No credit card is required.. Paying for a higher tier buys more volume and more leverage — it never unlocks a capability we were holding back.
If it turns out not to be for you, you have paid nothing and there is nothing to cancel.