SECURITY
Dryvn protects people and organizational data through encrypted transport, private networking, tenant-aware authorization, PostgreSQL Row-Level Security, least-privilege identities, managed secrets, hardened delivery pipelines, auditability, monitoring, backups, and controlled infrastructure access.
DEFENSE IN DEPTH
Dryvn applies independent controls across the network edge, private infrastructure, application runtime, tenant authorization, database access, identity, secrets, software delivery, monitoring, and recovery.
A failure in one layer should still meet another boundary.
PUBLIC EDGE
Public application traffic crosses managed transport and edge controls before it can reach private workloads.
Dryvn's public services are delivered over HTTPS using managed TLS certificates and a modern load-balancer TLS policy with TLS 1.2 as the minimum supported protocol. TLS 1.0 and TLS 1.1 are rejected.
Dryvn places Cloud Armor protections in front of public API traffic, providing edge-level rate controls and managed web-application firewall protections before requests reach application workloads.
Edge protection reduces abusive traffic without claiming that any system is immune from attack.
PRIVATE INFRASTRUCTURE
Application compute and data services remain behind private networking boundaries rather than accepting direct internet traffic.
Dryvn keeps application workloads behind private networking boundaries. Public traffic terminates at the HTTPS load-balancing layer, while application compute remains inside the VPC without direct public addressing.
Public access stops at the edge.
Dryvn uses VPC networking, dedicated subnets, narrowly scoped firewall controls, and workload-specific access paths so services communicate only across the ports and relationships required by the platform.
Network access follows workload need — not broad subnet trust.
DATABASE SECURITY
Database access combines private addressing, verified encrypted connectivity, and a restricted application identity.
Dryvn runs PostgreSQL on Cloud SQL using private addressing. Public IPv4 access is disabled, and application-to-database communication stays within private cloud networking.
People data does not need a public database endpoint.
Dryvn uses verified encrypted database connectivity so application workloads establish secure connections to the expected database service rather than relying on encryption alone.
TENANT BOUNDARIES
Dryvn is multi-tenant by design. Tenant separation is reinforced through authenticated tenant context, application authorization, restricted database roles, and PostgreSQL Row-Level Security.
Application authorization determines what the request may do. Row-Level Security reinforces which tenant rows the database will expose.
PostgreSQL Row-Level Security policies reinforce tenant separation close to the data itself, adding a database-level control to the authorization decisions already enforced by the application.
RLS reinforces application authorization; it does not replace it.
IDENTITY AND AUTHORIZATION
Authentication, tenant context, authorization, and enterprise identity controls work together before protected resources are accessed.
Dryvn uses authenticated sessions and signed token-based security controls to establish identity, tenant context, and authorization before protected application resources are accessed.
Dryvn applies role-aware authorization so access can be scoped around the responsibilities a user has inside the organization, following the principle of least required access.
SAML-based single sign-on is available for organizations that require centralized enterprise authentication and identity-provider integration.
LEAST PRIVILEGE
Normal application work should not require project-wide cloud privileges, host administration, unrestricted secrets, or database administration.
Dryvn separates runtime, deployment, and administrative identities and scopes cloud permissions around the resources each workload actually requires.
Compromise of one workload should not automatically become control of the platform.
Dryvn application workloads run under dedicated unprivileged identities with restricted filesystem access, hardened service configuration, and minimized runtime privileges.
Production secrets and credentials are managed through Google Cloud Secret Manager with resource-scoped access, least-privilege runtime identities, controlled rotation, and retirement of superseded secret versions.
Applications receive only the secrets required for their workload.
Normal application traffic uses a restricted application database identity. Privileged database administration and schema migration activities run through separate controlled operational workflows.
Privileged database operations stay outside normal application runtime access.
SOFTWARE SUPPLY CHAIN
Review, identity-bound delivery, immutable artifacts, and vulnerability detection form part of the release path rather than being added after deployment.
Dryvn uses controlled CI/CD pipelines with workload identity, protected production deployment paths, automated tests, security scanning, and immutable release artifacts.
Dryvn production releases are built before deployment, scanned, versioned, and deployed as immutable artifacts rather than cloning application source and installing mutable dependencies during server startup.
Dryvn combines dependency analysis, static security checks, artifact vulnerability scanning, and cloud security detection as part of the production security baseline.
DETECTION AND EVIDENCE
Cloud findings, audit evidence, and actionable monitoring help operators understand security-relevant changes and investigate events.
Google Cloud Security Command Center and monitoring controls provide security findings and infrastructure visibility across the production environment.
Dryvn maintains administrative, system, sensitive-service data-access, application-security, and infrastructure logs to support operational monitoring and incident investigation.
Security controls need evidence too.
Dryvn monitors security and operational signals for high-risk administrative activity, service failures, authentication abuse, unusual secret access, infrastructure health, database health, and backup status.
PRODUCTION ACCESS
Administrative access to production infrastructure is controlled through IAM-governed access, hardened host controls, scoped administrative network paths, and strong privileged authentication.
Administrative access is separated from public application traffic and tied to governed identities rather than persistent project-wide credentials.
RECOVERY AND AVAILABILITY
Recovery controls and resilient security-state services help keep data protection, authentication, revocation, and access controls available during infrastructure failure.
Dryvn maintains automated database backups, point-in-time recovery, deletion protection, backup monitoring, and recovery procedures as part of the production data-protection baseline.
Dryvn's production architecture removes avoidable single points of failure across application compute, database services, and security-relevant session infrastructure.
Authentication, revocation, rate limits, and application access should not depend on one machine staying alive.
Dryvn protects Redis traffic with transport encryption and uses a resilient Redis tier for security-relevant state such as sessions, token revocation, account protection, and rate limiting.
GOVERNANCE
Dryvn's production governance model separates responsibilities across runtime, deployment, and administrative access and minimizes permanent privileged access.
Technical boundaries are reinforced by ownership, review, separation of duties, and monitored administrative access.
A secure application is not enough if the infrastructure around it can be changed without control.
INFRASTRUCTURE OPTIONS
The shared Dryvn platform is protected through layered tenant isolation. Dedicated and regional architecture adds another boundary where organizational policy or infrastructure requirements call for it.
Dryvn's architecture supports controlled regional and dedicated deployment patterns for organizations with stronger infrastructure, governance, or data-residency requirements.
Dryvn's shared SaaS architecture uses layered tenant isolation across the application and database. Organizations with additional isolation requirements can choose dedicated infrastructure.
Application-level tenancy for most organizations. Infrastructure-level isolation when the requirement calls for it.
Eligible Standard and Pro customers can add dedicated infrastructure at a discounted infrastructure rate. No public discount amount is asserted.
Dryvn's shared SaaS platform uses layered tenant isolation, private networking, RLS, least-privilege identities, and application authorization. Dedicated infrastructure adds another infrastructure boundary for organizations whose internal policies or architecture requirements call for stronger isolation.
Enterprise deployments can incorporate additional identity, governance, infrastructure, integration, and implementation requirements where scoped.
DRYVN COPILOT
Copilot uses task-specific authorized context, bounded skills, managed inference, strict action validation, human approval, and retained audit evidence. It does not sit outside Dryvn's security model.
Named Copilot access never expands the underlying user's authority. Every retrieval remains tenant-scoped and is re-authorized as the human user.
Copilot can work only with context the requesting user is allowed to use.
Dryvn identifies the task, retrieves authorized evidence, prefers aggregate context, replaces identity fields with temporary references where appropriate, and rehydrates authorized display information locally after the response.
Pseudonymization reduces exposure but is not the same as complete anonymization.
Copilot skills define which categories are typical, controlled, or excluded by default.
The managed model receives a bounded task payload. It has no credential or unrestricted route into Dryvn systems.
A data-changing proposal passes through all normal Dryvn controls before the user can approve it.
All data-changing Copilot actions require explicit human approval.
Customer documents, retrieved content, and tool results are treated as untrusted data rather than instructions that can override Dryvn policy.
Conversation state is controlled by Dryvn. Provider-hosted persistent memory is disabled and only task-relevant context is sent for each request.
Standard inference uses an approved managed Google Cloud AI service through the configured regional or jurisdictional endpoint. Provider request-response logging and persistent interaction storage are disabled.
The model can propose. Dryvn decides what is allowed.
SECURITY FAQ
Yes. Public application traffic uses HTTPS with managed certificates and TLS 1.2 as the minimum supported protocol. TLS 1.3 is also supported, while TLS 1.0 and TLS 1.1 are rejected.
The application workload does not use a public IP. Public traffic terminates at the HTTPS load-balancing edge before reaching private application networking.
No. Production Cloud SQL uses private addressing with public IPv4 access disabled.
Dryvn combines authenticated tenant context, application authorization, restricted database roles, and PostgreSQL Row-Level Security so tenant isolation does not depend on one layer.
PostgreSQL Row-Level Security applies database policies that reinforce which tenant rows a database session may access. It complements rather than replaces application authorization.
Production secrets and credentials are managed in Google Cloud Secret Manager with resource-scoped access, controlled rotation, and retirement of superseded versions.
Production deployment pipelines use Workload Identity Federation instead of static Google Cloud deployment keys.
Yes. SAML-based SSO is available for organizations that require centralized enterprise authentication and identity-provider integration.
Yes. Cloud Armor provides managed web-application firewall protections and edge rate controls in front of public API traffic.
Yes. The release baseline includes dependency analysis, static security checks, artifact vulnerability scanning, and deployment security gates.
Yes. The production baseline includes automated Cloud SQL backups, point-in-time recovery, deletion protection, backup monitoring, Firestore recovery protection, and documented recovery procedures.
Yes. Organizations with additional infrastructure-isolation requirements can choose dedicated application, database, and network boundaries with scoped operational controls.
Yes. Eligible Standard and Pro customers can add dedicated infrastructure at a discounted infrastructure rate. The discount amount is scoped commercially and is not asserted on this page.
No. Shared Dryvn uses private networking, application authorization, restricted database roles, RLS, least-privilege identities, and multiple tenant boundaries. Dedicated infrastructure adds another boundary for organizations whose policies require it.
Dryvn does not claim a certification until the relevant independent certification or audit has been completed.
SECURITY
Talk to us about tenant isolation, enterprise identity, governance, regional architecture, or dedicated infrastructure for your Dryvn deployment.