Security Overview

Last Updated: July 29, 2026

Summary

Alkera is an AI agent for data teams that replaces traditional coding harnesses. Alkera is accessible via an IDE extension, a CLI, and a web application. It runs as Alkera-managed SaaS or is self-hosted by the customer (VPC/on-premises) from the same signed images. Our security model keeps secrets and large language models (LLMs) in separate trust zones: LLMs can propose actions against authenticated sources but can never directly read or use credentials, enforced via OS-level sandbox mechanisms.

Architecture and Trust Boundaries

Agent Isolation and Credential Guardrails

Tool call permissions: All tool calls are classified into permission levels: read, write, destroy, or egress. For tools like bash commands and SQL, their abstract syntax trees are parsed to analyze permission level (e.g., a dangerous UPDATE can be detected within a nested CTE). For SQL, when the underlying database driver permits it, read-only access is also gated again at the driver level.

Tool calls depend on plugins where the user or administrator has already configured credentials, so credentials are never handled by the agent. Users must explicitly approve tool calls with permission levels above read and can configure their policy for approving repeated similar tool calls.

File-system safety: Sensitive paths, including Alkera-created files holding encrypted credentials, are hard-blocked for access by the agent at the process and operating system level via OS-level sandbox mechanisms.

Authentication and access: Industry-standard implementations of SAML & OIDC are supported with hardening techniques including XML-DSig and nonce defense. SCIM 2.0 is supported for provisioning/deprovisioning, including revoking live sessions. MFA (TOTP) on accounts can be configured. Roles can be synced from the IdP to automatically configure the permissions for new users.

For authentication to plugins, including those that connect to external data sources, these can be configured by different methods with different security trade-offs:

• Local-only — Users enter their own credentials locally, and they are stored locally.
• Shared and synced — Admins enter shared credentials into the control plane, and they are synced to users’ machines.
• Shared and proxied — Admins can enter shared credentials into the control plane, and users’ machines access the connections via a proxy through the control plane, so credentials are not sent and access can be cleanly revoked at any time.
• OAuth — Admins can allow users to authenticate to data sources (often warehouses) via OAuth to maintain existing user permissions within these sources. Certain sources, including Snowflake and Databricks, support a localhost OAuth callback with no extra admin configuration besides providing the instance URL, whereas sources including BigQuery require admin configuration of server-side secrets, including an OAuth client ID and secret.

Data Protection and Encryption

Logging and Auditing

There is a configurable append-only audit trail of logins and important actions, including billing and security configuration changes. All audit logs are tamper-evident via a SHA-256 hash chain, with the option for export to SIEM. Agent actions can also be audited with granularity up to every single message and tool call.

Platform & Supply-chain Hardening

Standard security practices for web security, including strict CSP, CORS, and security headers, are utilized. Alkera software packages and container images are cryptographically signed using Cosign and include SLSA provenance to support artifact integrity and build traceability. We generate CycloneDX Software Bills of Materials (SBOMs) for released artifacts and scan them for known security vulnerabilities. Container images are built from pinned base images to reduce supply-chain risk. For software packages on users’ machines, with proper operating system support, they are fully code-signed and notarized.

Compliance & Certifications

Alkera is in process and engaged for SOC 2 Type II, ISO 27001, GDPR, and HIPAA with active external auditors. We are aligned with standard frameworks, including SOC 2 Trust Services Criteria, ISO/IEC 27001, GDPR, and CSA Cloud Controls Matrix / CAIQ. Compliance status letters, data processing agreement (DPA), and a completed CSA CAIQ / SIG-Lite questionnaire are available on request.

Risk Management

Alkera systems enforce multi-factor authentication (MFA) for access to production systems and administrative tooling. Role-based access control (RBAC) with least-privilege provisioning is used throughout the company. Periodic access reviews are in place with automatic de-provisioning upon termination or role change.

Independent third-party penetration testing is scheduled, with at least an annual cadence. Automated scanning is utilized to detect known security vulnerabilities in all dependent software packages. A public vulnerability disclosure program is also in place.

Centralized logging and continuous 24/7 monitoring and alerting systems are in place across production systems. Documented incident response plans with commitments to notify customers of confirmed security incidents involving them are in place. Regular encrypted backups are also performed.

Confidentiality and IP assignment agreements are executed by all employees and contractors. Background checks are performed for employees with access to production systems, where legally permitted. Mandatory security awareness training is required at onboarding and on a recurring annual basis. Formal vendor risk assessment and due diligence is required prior to onboarding any subprocessor. Data residency options and a subprocessor list are available upon request.

Contact

Please contact Alkera at contact@alkera.ai for any inquiries related to security and compliance.