Mekovault

Security Policies

Translation for reference. The Spanish version is the binding one.

Effective: 2026 · Last review: August 31, 2026

Mekovault manages the identity lifecycle in Google Workspace and in other platforms that may be connected in the future. To work, it receives highly sensitive credentials (Service Accounts with administration permissions). This document describes how we store them, how we use them, and how the Customer can audit every use.

It is written as a reference for security teams, auditors and enterprise buyers. It supplements, and does not replace, the Privacy Policy, the Terms and the DPA.

1. Scope

These policies apply to every credential the Customer provides to Mekovault to operate on its corporate directory, including but not limited to:

  • Google Workspace: Service Account JSON file with Domain-Wide Delegation.
  • Any other integration credential for other platforms, people systems or directories that Mekovault may support in the future.

2. Storage architecture

2.1 Physical separation of secrets and metadata

No credential is stored in Mekovault’s relational database. The architecture separates two planes:

  • Metadata plane (PostgreSQL, host mekovault-data): stores only a pointer to the secret (the key name inside the vault), the provider, the primary domain, timestamps and the results of the last health check. Row-Level Security by company_id.
  • Secrets plane (Infisical, host mekovault-vault): self-hosted instance of Infisical on a private Tailscale network, not exposed to the public Internet. It contains the actual values (for example, the complete Service Account JSON).

A bug or compromise of the metadata service does not expose credentials: the secrets require separate authentication against Infisical through a distinct machine identity.

2.2 Per-tenant isolation (hard multi-tenancy)

Each tenant receives a dedicated Infisical project (example: setting-cl-415514, mmglatam-com-872039). Secrets are never shared. Consequence:

  • The blast radius of any failure in Mekovault’s code that builds the project reference incorrectly is limited to the same tenant: it cannot read, list or touch secrets of other customers.
  • Infisical’s access policies reject requests to projects for which Mekovault’s machine identity has no permission, even if it knows them by name.

2.3 Encryption

  • In transit: TLS 1.2+ mandatory on all connections (portal HTTPS, PostgreSQL with SSL, Mekovault → Infisical channel, Mekovault → Google channel). We do not accept unencrypted connections.
  • At rest: secrets are encrypted in Infisical with the vault’s master key (AES-256-GCM); the vault volume is encrypted at disk level (LUKS / EBS encryption). PostgreSQL runs with disk encryption.
  • Service key rotation: JWT signing keys and the credentials of the Infisical machine identity are rotated at least every 12 months and upon any suspected compromise event.

2.4 Network and perimeter

  • All backend machines (mekovault-app, mekovault-data, mekovault-obs, mekovault-vault) are connected through Tailscale over WireGuard.
  • mekovault-vault has no public IP and no port open to the Internet. It only listens on the private Tailscale interface. It cannot be reached directly even from the public frontend (Vercel).
  • Administrative access by the Mekovault team requires Tailscale with MFA plus a managed SSH key. No personal root SSH credentials on any host.

3. Use of credentials

3.1 Least privilege in the request

When connecting the directory, Mekovault requests exactly the scopes it needs, not one more. We publish the full list in the connection Wizard guide and reproduce it here:

Google Workspace: Domain-Wide Delegation

  • admin.directory.user: create, suspend, reactivate and modify users.
  • admin.directory.user.security: password reset and termination of active sessions (SSO revocation).
  • admin.directory.orgunit: move users between OUs during onboarding/offboarding.
  • admin.directory.group: create/delete groups and distribution lists.
  • admin.directory.group.member: add/remove group members.
  • admin.directory.domain.readonly: read-only access to the list of domains (to validate that the SA operates on the correct domain).
  • admin.directory.customer.readonly: read-only access to the Google customer account data (for aggregated reports).

We do not request: access to Gmail (Mail scopes), Drive, Calendar, Chat, or any user content data. Mekovault does not read emails or files.

Other platforms

When a new platform is connected, we will publish in this same section the exact list of permissions it requests before it becomes available to Customers. The criterion is the same: only account administration permissions, never access to people’s content.

3.2 Never in logs, never outside the process

  • The adapters load the secret into memory right before calling the external provider and discard it when the request ends.
  • The structured logger automatically filters any field whose name contains password, secret, token, key or credential. Log entries show the truncated hash of the request-id but never the content of the secret.
  • There are no vault backups in unencrypted external storage. Snapshots are encrypted with the same vault master key.

4. Auditing of every use

4.1 Immutable log credential_usage_log

Every time Mekovault performs an operation on the Customer’s directory with the stored credentials, a record is persisted in the credential_usage_log table with:

  • Who: ID and email of the Mekovault user (or worker/scheduler identifier) that originated the operation.
  • Why: mandatory human-readable purpose (example: “Onboarding user@empresa.cl via ticket #4213”, “Nightly health check”, “Bulk deprovision batch #123”).
  • What: exact operation (create_user, suspend_user, reset_password, add_group_member, etc.).
  • Which scopes: list of OAuth scopes / Application permissions consumed.
  • On which resource: user email, group, OU, or other identifier (without sensitive content data).
  • Result: success / failure / partial, error_code, error_message, duration_ms, request_id to correlate with nginx.
  • When: UTC timestamp with millisecond precision.

4.2 Immutability

The table has PostgreSQL triggers that reject any UPDATE and DELETE. Not even the Mekovault team with root access can modify an individual record. The only way to purge is the retention worker with explicit published rules (minimum retention of 24 months, configurable per Customer up to 84, or until the tenant is deleted, whichever comes first), which runs with SECURITY DEFINER and records the purged batch.

4.3 Visibility for the Customer

Every tenant admin can view the log at:

  • https://app.mekovault.com/<your-slug>/admin/credential-usage

Filters by provider, result, operation, date range and actor. The query uses Row-Level Security by company_id: each tenant sees exclusively its own records.

Scheduled signed CSV/JSON export for external auditors is planned for Milestone 7. In the meantime, it can be requested on demand by writing to soporte@mekovault.com.

4.4 Correlation with the audit system

credential_usage_log is specific to calls to the external directory. There is a second table, audit_events, which records human actions inside the portal (login, ticket approval, role creation, etc.). Both share request_id to reconstruct a complete chain: “admin X approved ticket Y, which triggered operation Z on user W in Google, with scope A, result B”.

5. Internal access control (Mekovault staff)

  • Administrative access to the hosts requires Tailscale with MFA and a personal SSH key. There are no shared accounts.
  • No member of the Mekovault team needs, or has by default, the ability to decrypt a Customer’s individual secrets in order to operate the platform.
  • Access to the Infisical vault is restricted to members of the platform team. Policy changes are recorded in Infisical’s internal audit.
  • Access to the production database is done through named accounts with RLS enabled. The mekovault_superadmin account (BYPASSRLS) has restricted use and leaves records in audit_events.

6. Incident response

  • Notification to the affected Customer within 72 hours of confirming an incident involving its personal data or its credentials (GDPR art. 33, Ley 21.719 Chile art. 33).
  • Forced rotation of all credentials of the affected tenant and revocation of the connection: the Customer must reconnect the directory with a new Service Account (we do not reuse the compromised one).
  • Post-mortem report to the Customer with the timeline, scope, countermeasures and lessons learned.
  • Responsible vulnerability disclosure channel: security@mekovault.com. We respond within ≤ 48 business hours.

7. Exercise of rights and portability

If the Customer terminates the service or requests complete deletion of its data:

  • Deletion of the Infisical project (atomically deletes all of the tenant’s secrets).
  • Cascading deletion of the tenant’s rows in PostgreSQL, including the connection and the identity catalog.
  • The tenant’s credential_usage_log is kept until the tenant is deleted or for 24 months, whichever comes first (Ley 21.719 art. 12, GDPR art. 30). When the tenant is deleted, it is removed together with the rest of its data; Mekovault keeps only its own record with counters and no personal data. The Customer may request its pseudonymous hash beforehand if its internal policy requires it.

8. Reference frameworks

We align the practices described above with:

  • SOC 2 Type II: controls CC6 (access), CC7 (monitoring), CC8 (change management). No certification planned for now: we use the framework as a guide for controls, not as a promise of audit.
  • ISO/IEC 27001: controls A.5 (information), A.8 (assets), A.9 (access), A.12 (operations), A.16 (incidents).
  • GDPR (EU 2016/679): arts. 25 (privacy by design), 30 (records of processing activities), 32 (security of processing), 33 (notification).
  • Ley 21.719 (Chile): arts. 12 (records of activities), 33 (breach notification), 34 (security measures).
  • Google Workspace: terms of use of the Admin SDK Directory API and of the Marketplace program.

9. Questions and contact

Security teams of current or prospective Customers may request:

  • A copy of our signable DPA (Data Processing Agreement).
  • Security questionnaire (CAIQ, VSA, SIG Lite): we answer within ≤ 5 business days.
  • Evidence of internal audits and pen-testing reports (under NDA).

Write to us at security@mekovault.com or contact us through the contact form.

10. Changes to this policy

We publish the date of the last review in the header. Material changes (for example, new requested scopes, changes to the retention model) are communicated 30 days in advance by email to the tenant administrators and are reflected in the site’s public history.

This document describes operational controls and does not constitute formal certification. For current or in-progress certifications, see the Trust Center (coming soon at trust.mekovault.com) or request it through security@mekovault.com.