Security & architecture

Four commitments guide the platform's technical decisions:

• The AI model does not query databases directly nor generate data: it invokes typed functions and returns the answer with its source.
• When the data does not support the answer, the system explicitly abstains rather than inferring.
• Every operation is recorded in append-only logs: arguments, result, duration, and actor.
• Personal data processed with the data subject's authorization is anonymized rather than hard-deleted, preserving the referential integrity of audit records.

The architecture is designed to keep the language model out of the data's critical path:

• Deterministic tool-calling: the AI model receives responses from typed functions (Python). It does not generate SQL, does not query tables directly, does not write to production.
• No text-to-SQL: queries against productive databases go through code-reviewed and tested functions — the model chooses which function to call, not how to query the database.
• Testable composer: the orchestration logic between tools, database, and final response is separate from the model and covered by automated tests.
• Fail-loud by design: if a tool cannot answer with evidence, it does not invent an output — it fails observably and the failure is recorded.

The language model provider and its inference region depend on the product version:

Client data — internal databases, documents, historical records — remains on the infrastructure described in section 6. What travels to the LLM provider are the prompts constructed by Alicanto's orchestrator and the structured response the model returns.

Controls available today in the public version:

• Authentication with password + Google OAuth (OpenID Connect).
• Passwords hashed with Argon2id (no fixed compute cost, parameters tunable as hardware advances).
• TOTP MFA mandatory: 6-digit codes every 30 seconds, secrets encrypted with Fernet (AES-128-CBC + HMAC-SHA256), anti-replay protection, and ten recovery codes hashed with Argon2.
• 15-minute access tokens, 30-day refresh tokens with rotation and reuse detection.
• HttpOnly + Secure + SameSite=Lax cookies (__Host- prefix in production) for tokens; tokens never exposed to JavaScript.
• CSRF protection via double-submit cookie + SameSite.
• No third-party telemetry in the client (no Google Analytics, no Mixpanel, no tracking pixels).

Enterprise controls:

• Corporate SSO via SAML 2.0 / OIDC against the client directory (Azure AD, Okta, Google Workspace, Keycloak): available under contract.
• Per-institution role configuration and access audit log.
• Automated user provisioning and de-provisioning via SCIM: available under contract.

• Encryption in transit: TLS 1.2+ mandatory across all services; HSTS with one-year max-age and includeSubDomains in production.
• Encryption at rest: AES-256 managed by Google Cloud over Cloud SQL (PostgreSQL) and Cloud Storage; filesystem encryption in Cloud Run.
• Password hashing: Argon2id.
• Application-level symmetric encryption of sensitive secrets (TOTP seeds, long-lived tokens): Fernet (AES-128-CBC + HMAC-SHA256) with rotatable keys.
• Secrets management: Google Secret Manager with access mediated by Workload Identity Federation. JWT signing keys, TOTP encryption keys, token-hashing keys, and third-party API keys are never persisted in code or local environment variables.
• Credential rotation: Secret Manager secrets can be rotated without redeploy; long tokens are hashed (HMAC) before being stored in the database.

Enterprise controls:

• Customer-Managed Encryption Keys (CMEK): the institution provides and controls the master key for data at rest. It can rotate or revoke it at any time, stopping Alicanto's access. Available under contract.

Residency — public version (current state):

• Data at rest: GCP us-central1 region (Iowa, United States) — relational databases, object storage, backups.
• Compute and orchestration: Cloud Run in us-central1.
• LLM inference: provider regions (see section 3) — the constructed prompt and the structured response are the only things that travel between regions.

Residency — enterprise version:

• Deployments in GCP Santiago region (southamerica-west1) when the client requires it — data at rest, compute, and orchestration.
• BYOC: in the client's GCP tenant, in the region the institution defines as its residency policy.
• LLM inference in the agreed Vertex region (section 3).

Isolation model — public version:

• Logical multi-tenancy: single Cloud SQL instance, single schema, isolation enforced by mandatory application filters (every query is filtered by the user's identity).
• Public shared data (CMF, Central Bank) in the same schema, read-only for all users.
• Ephemeral, purpose-specific tokens (link codes, password reset, TOTP challenges) with short TTL and scheduled cleanup.

Isolation model — enterprise: PostgreSQL Row-Level Security or dedicated instance per institution, depending on the contract scope.

• PostgreSQL Row-Level Security: tenant isolation is enforced at the database engine level. Every row is tagged with its tenant and RLS policies automatically filter every query — even if the application contains a bug, the database does not return data from another tenant.
• Dedicated instance per institution: when the contract scope justifies it (volume, sensitivity, regulatory requirement), the database is provisioned as an exclusive instance, with no shared compute or storage with other clients.
• BYOC (Bring Your Own Cloud): the institution provides the GCP project and Alicanto deploys inside that tenant. Data never crosses to Alicanto's infrastructure.

Every significant operation is recorded in append-only tables protected by database triggers that block UPDATE and DELETE at the engine level:

• agent_actions: one row per agent turn — proposal type, parameters, result, duration, associated job.
• audit_events: data ingestions, token-based access, exercises of data subject rights, identity merges.
• messages: conversational history with direction, author, type, body, and references to associated artifacts.
• jobs: worker executions with status, errors, and duration.

Every agent response includes a verifiable reference to the source: period, identifiers, subset of records that support the answer. A response without a traceable reference is not delivered — the agent abstains.

The processing of personal data on the public website is described in detail in the Privacy Policy. For personal data processed within the SaaS product (where Alicanto acts as data processor for the client institution), the terms are governed by the Data Processing Agreement (DPA) signed with each client.

• Anonymization rather than hard delete: when exercising the right to deletion, email, password hash, OAuth identifiers, and name are nullified, leaving a tombstone record that preserves the integrity of audit logs.
• PII redaction in feedback and telemetry: emails, RUT, and account numbers detected in free text are replaced with markers ([EMAIL], [RUT], [ACCOUNT]) before storage.
• Retention by category documented in the Privacy Policy.
• Single channel for exercising rights: privacidad@alicantoai.cl.

Current platform subprocessors (not the public website's; the site list lives in the Privacy Policy):

• Daily automatic Cloud SQL backups with configurable retention; point-in-time recovery enabled.
• Versioned database migrations (Goose) executed through a dedicated DDL user, separate from the CRUD user used by the application.
• Maintenance mode that can be activated during deployments to prevent writes in critical windows.
• Cloud Run stateless on disk: instances are ephemeral; state lives in Cloud SQL and Cloud Storage.
• Cloud Tasks as a decoupled queue between webhook and worker, with conservative rate limits to protect backends.

Enterprise controls:

• RTO/RPO documented in the contract according to the criticality of the use case.
• Disaster recovery exercises with the client when the institution requires them.

• CI/CD pipeline on GitHub Actions with authentication to GCP via Workload Identity Federation (no long-lived service account credentials).
• Docker images built on every commit with a unique SHA and published to Artifact Registry.
• Migrations applied as an isolated Cloud Run Job before application deployment.
• Mandatory code review before merging to main for every change that touches productive paths.
• Audited dependencies: periodic review of security advisories for packages in use.
• Deployment secrets (service keys, third-party tokens) injected at runtime from Secret Manager, never committed.

Roadmap (section 13):

• Automated SAST and dependency scanning as a CI gate.
• Container image signing (Cosign / Sigstore) and verification at deployment.
• Formal penetration testing program with independent third parties.

Chilean regulatory frameworks we design to align with:

• Law 19.628 on the Protection of Private Life (in force).
• Law 21.719 on Personal Data Protection (full effect on December 1, 2026). We voluntarily apply its stricter guarantees during the transition regime.
• RAN 20.7 of the CMF on Operational Risk Management and Business Continuity (with the 2027 reform on the horizon).
• REDEC and regulatory reports D10, C11, R13 — relevant to our regulatory reporting automation services.

Certifications:

• ISO/IEC 27001 (Information Security Management System): in preparation.
• SOC 2 Type II (Trust Services Criteria — Security, Availability, Confidentiality): in preparation.

Consolidated summary of controls available under enterprise contract or on the implementation horizon. Timelines are indicative and concretize according to each client's commercial commitment:

If you discover a vulnerability in any of our assets (website, SaaS platform, infrastructure, dependencies), contact us at security@alicantoai.cl. We will confirm receipt within a reasonable timeframe and coordinate the disclosure cycle with you.

We ask the security research community to:

• Report the finding privately before disclosing it publicly, giving us reasonable time to remediate.
• Not access, modify, or disclose data belonging to other users; stop upon confirming the finding is valid.
• Not perform tests that degrade the service, generate denial-of-service, or spam other users.
• Operate within the applicable legal framework.

We publicly acknowledge — with the researcher's authorization — those who help us improve Alicanto's security posture. We do not yet operate a formal bug bounty program with monetary compensation; when we launch one, it will be announced on this page.

We update this page when a security control relevant to clients changes, when a new certification is issued, or when the roadmap advances. The date visible at the top of the page corresponds to the last material update; minor editorial changes do not update the date.

Enterprise clients under DPA are notified of material changes with reasonable anticipation through the channel agreed in the contract.