PractikAI's Technology & Security Overview
- Danny Lilley
- Jul 9
- 6 min read
Building SaaS & AI with Security, Privacy, and Trust
PractikAI builds custom SaaS applications and AI agents for transportation, logistics, and supply chain business workflows. This article is written for the technical stakeholders and security teams evaluating us as a partner. It walks through our architecture, integration model, AI safety practices, and security posture.
Everything below describes how we deliver Custom Solutions today. The final section, "Where we're going," covers how the same principles apply to any productized platform we build next.
How we deliver
Every PractikAI Technology Solutions engagement today is delivered as a single-tenant deployment. Each client gets its own dedicated application infrastructure, data stores, and agent configurations. We don't run shared tenancy with logical separation between clients. Because tenant isolation is structural rather than logical, this eliminates cross-tenant data exposure risk at the infrastructure layer, and there's no path for one client's data to reach another's.
PractikAI Technology Solutions are deployed under one of three models, chosen during scoping:
PractikAI-Managed Cloud. We provision, operate, and monitor the environment in our own cloud account. This is the fastest path to deployment.
Client Cloud. Deployed into your cloud account (Azure, GCP, or AWS) under your billing and ownership. We operate with scoped credentials. This is the best fit when data residency in your tenant is required.
Hybrid. The application plane runs in PractikAI's cloud; sensitive data stores and designated integrations stay in yours.
All three share the architecture below.
Architecture
Cloud-native and provider-agnostic. Reference architecture patterns are expressed in managed cloud services and open standards rather than vendor-specific products. We prioritize Microsoft Azure, with optional support for Google Cloud Platform or Amazon Web Services per engagement.
Flexible application architecture. Workloads are designed in the topology best suited to the problem: monolithic, hybrid, or microservices. We choose based on what the workload actually needs, not on architectural preference. The goal is to balance development velocity, operational cost, and scale.
Containerized deployment. Most workloads run on serverless container platforms (Azure Container Apps, Google Cloud Run, AWS ECS). Kubernetes orchestration is supported optionally for large, complex, or highly customized workloads.
Hardened artifacts. Containers and VMs are built from hardened base images with automated vulnerability scanning.
Stateless services. Application logic is stateless and horizontally scalable. Durable data lives in managed, provider-native stores (relational, object, vector) with built-in replication and backup.
API-first. Services expose REST APIs and event-driven interfaces. Client-facing surfaces sit behind managed application gateways or load balancers.
Infrastructure as Code where it's warranted. For large-scale or highly custom environments requiring automated repeatability, we deploy Infrastructure as Code (IaC). Smaller or simpler scopes may use direct provisioning where IaC overhead isn’t warranted and doesn't pay for itself.
Environment isolation. Where we use multi-stage environments (development, staging, production), they're structurally segregated. Production networks, credentials, and data stores are isolated from non-production.
Tenant and data isolation
Dedicated environments per client. Each engagement runs in its own project, subscription, or resource group, not a shared account with logical separation. Network boundaries, IAM, and data stores are per-client.
No cross-client data paths. No service, database, or credential is shared across client engagements.
Data residency. In Client Cloud deployments, client data does not leave the client's cloud tenant except for traffic to approved AI model endpoints. PractikAI-Managed deployments are region-pinned per engagement.
Data processing architecture. Client data is processed and retained in its original, unaltered schema within dedicated environments. All processing, model execution, and reporting is confined strictly to the client's single-tenant instance. There is no cross-engagement aggregation or global system analysis.
AI and agent architecture
PractikAI’s AI-enabled solutions follow a set of principles designed to make agent behavior predictable, auditable, and safe:
Model provider abstraction. Agents interact with language model providers through a thin abstraction layer. Model choice is configurable per workflow and can be changed without rewriting business logic. Clients with preferred providers or data-residency requirements can be accommodated.
Zero-retention endpoints where available. Where providers offer zero-retention or no-training API tiers, those tiers are used by default for workloads touching client data.
Deterministic logic where it fits. Agentic reasoning is reserved for tasks that genuinely require it. Workflows that can be expressed deterministically are implemented in code. This is faster, cheaper, more testable, easier to audit.
Structured tool use. Agents interact with external systems through a defined set of tools with typed inputs and outputs, not through freeform code execution. Tool surfaces are explicit, reviewable, and governed.
Prompt injection defenses. System prompts and trusted instructions are isolated from untrusted content (documents, emails, web pages, user inputs). Tool invocations triggered by untrusted content are subject to allow-listing, and for material actions they require explicit human approval.
Human-in-the-loop for material actions. Actions with financial, legal, or operational consequences (sending external messages, committing transactions, modifying records of record) require human approval by default.
Output validation. Agent outputs are validated against expected schemas and business rules before being acted on. If an output is unparseable or out-of-bounds, the system retries, falls back, or escalates. It doesn't fail silently.
Full audit trail. Every agent action is logged with enough detail to reconstruct the reasoning path after the fact: the model invocation, the tools called, any human override, the decision.
Integration patterns
PractikAI integrates with client systems through standards-based, well-supported patterns:
REST APIs. JSON over HTTPS, TLS 1.2 or higher, token or mTLS authentication.
Webhooks. Signed, verifiable event delivery in both directions.
SFTP and secure file transfer. For batch integrations and legacy counterparties.
EDI. AS2 and FTP-based EDI for logistics and supply-chain integrations.
Database and warehouse connectors. Read-only or scoped-write connectors to client-owned databases and warehouses.
Message queues and event streams. Cloud-native pub/sub for event-driven workflows.
MCP servers. Model Context Protocol hosts enabling secure, standardized LLM tool access to internal data and services
Integration credentials are client-owned, scoped to least privilege, and rotatable by the client at any time.
Observability and AI auditing
Every PractikAI environment includes operational and AI-specific observability.
Metrics, logs, and traces. Standard infrastructure and application telemetry aggregated in a central monitoring stack per environment.
Agent action auditing. Every model invocation, tool call, and agent decision is logged with timestamps, inputs, outputs, and correlation IDs. Client-visible where contractually agreed.
Quality evaluations. For agentic workflows, defined criteria (accuracy, completeness, safe-response rate) are measured on a sampled basis in production. Regressions surface through automated alerts.
Human review workflows. Sampled or exception-based agent outputs are routed to human reviewers per client configuration. Review outcomes feed back into prompt and model tuning.
Resilience and continuity
Backups. Managed data stores are backed up at a minimum daily cadence; point-in-time recovery is enabled where supported. Retention and RPO/RTO targets are set per engagement.
Model provider fallbacks. Where a workflow depends on an external model provider, a secondary provider is configured for failover where feasible.
Source code escrow. For Custom Solutions, source code escrow and continuity arrangements are supported as an option in the engagement agreement. These provide clients a defined path to source, configuration, and operational runbooks if specified trigger events occur.
Disaster recovery. Recovery procedures, including restoration from backup and redeployment from IaC where applicable, are documented per environment and validated on the cadence specified in the engagement.
Security
Encryption in transit. TLS 1.2 or higher (TLS 1.3 where supported) at all public edges and for service-to-service traffic crossing trust boundaries.
Encryption at rest. All managed data stores use provider-native encryption at rest. Customer-managed keys (CMK / BYOK) are supported in Client Cloud deployments where the underlying provider supports them.
Identity and access. PractikAI personnel access client environments through SSO with enforced MFA. Standing production access is limited to a named on-call engineering group; all other access is just-in-time and logged. Service-to-service authentication uses workload identities rather than long-lived static keys wherever supported. Secrets live in managed vault services, never in source code, build artifacts, or config files.
Customer-facing access. Client applications prioritize Single Sign-On via OIDC and OAuth 2.0, with optional SAML. MFA can be enforced through the client identity provider, and role-based access control is applied within the application.
Secure SDLC. Code review is required for all merges to main. Automated static analysis and dependency scanning run in the CI pipeline. Direct commits to production branches are not permitted.
Incident response. Documented incident response procedure with defined roles, communication protocols, and client notification commitments. Notification timelines are set in the applicable engagement agreement.
Data retention and deletion. Retention aligned to engagement terms. On termination, client data is returned in an agreed-upon format and then deleted from all PractikAI-controlled systems within the contractually specified window.
Compliance posture
SOC 2. PractikAI is not currently SOC 2 certified. The security controls described on this page (structural tenant isolation, zero-retention model endpoints, encrypted data stores, secure SDLC, and the rest) are already in place and form the foundation of a planned SOC 2 Type I engagement. Current status is available under NDA.
Privacy regulations. Architecture supports GDPR and CCPA data-subject rights (access, deletion, portability) through defined operational procedures. Specific obligations are addressed per engagement based on the data involved.
Sector-specific frameworks. HIPAA, PCI DSS, and similar frameworks are addressed on a per-engagement basis where in scope. PractikAI is not currently certified under these frameworks.
Data residency. Client Cloud and Hybrid deployments directly support customer-specified data residency. PractikAI-Managed deployments are region-pinned per engagement.
Where we're going
PractikAI's product direction is to productize patterns proven in current Custom Solutions into a multi-tenant SaaS platform. The architectural and security principles on this page (strong tenant isolation, encryption, model provider abstraction with zero-retention endpoints, structured tool use, human-in-the-loop, full audit trail, secure SDLC) carry forward. Existing Custom Solutions clients continue to be supported under the dedicated single-tenant model throughout their contract term.
A more detailed Technical & Security Overview is available under NDA. To request a copy or discuss a specific engagement, contact our team.
