A Team Agency LLC — Security Policy de A Team Agency LLC. Medidas técnicas y organizativas de seguri...
a_team_docs el 2026-06-17. Fuente: privacidad/ATeam_Security_Policy_v1_0.md
1.1 Objeto
Esta Security Policy establece las medidas técnicas y organizativas que A Team Agency LLC (en adelante, "A Team") implementa para garantizar la confidencialidad, integridad y disponibilidad de los datos personales, datos bancarios y datos operativos tratados en el marco de la prestación de sus Servicios.
1.2 Alcance
Esta Política aplica a:
Toda la infraestructura tecnológica de A Team, incluyendo la plataforma AGaaS (Agentic as a Service), los Agentes de IA y los sistemas de soporte operativo.
Los datos del Cliente, datos de Usuarios, Datos Bancarios y datos de configuración procesados en la plataforma.
El personal de A Team, contratistas y proveedores con acceso a sistemas o datos protegidos.
Las Entidades Operativas Locales (OpCos) autorizadas, que deben cumplir estándares equivalentes bajo el Intercompany DPA.
1.3 Principios rectores
Principio Descripción
Defensa en Múltiples capas de controles de seguridad que profundidad operan de forma independiente y complementaria.
Mínimo privilegio El acceso a datos y sistemas se otorga únicamente en la medida estrictamente necesaria para la función de cada rol.
Seguridad por diseño Los controles de seguridad se integran desde la concepción de cada funcionalidad, no como capa posterior.
Segregación de datos Los Datos Bancarios y datos KYC/KYB se almacenan sensibles y procesan en entornos lógicamente aislados del resto de la plataforma.
Trazabilidad y Toda operación significativa sobre datos auditoría sensibles genera un registro de auditoría inmutable.
Respuesta ante A Team mantiene un plan de respuesta ante incidentes incidentes activo, con plazos de notificación definidos por normativa.
1.1 Purpose
This Security Policy establishes the technical and organizational measures that A Team Agency LLC (hereinafter "A Team") implements to ensure the confidentiality, integrity, and availability of personal data, banking data, and operational data processed in the framework of providing its Services.
1.2 Scope
This Policy applies to:
All of A Team's technology infrastructure, including the AGaaS (Agentic as a Service) platform, the AI Agents, and operational support systems.
Client data, User data, Banking Data, and configuration data processed on the platform.
A Team staff, contractors, and providers with access to protected systems or data.
Authorized Local Operating Entities (OpCos), which must meet equivalent standards under the Intercompany DPA.
1.3 Guiding principles
Principle Description
Defense in depth Multiple layers of security controls operating independently and complementarily.
Least privilege Access to data and systems is granted only to the extent strictly necessary for each role's function.
Security by design Security controls are integrated from the conception of each feature, not as a subsequent layer.
Sensitive data Banking Data and KYC/KYB data are stored and segregation processed in logically isolated environments from the rest of the platform.
Traceability and Every significant operation on sensitive data audit generates an immutable audit record.
Incident response A Team maintains an active incident response plan with notification timeframes defined by regulation.
2.1 Cifrado en reposo
Todos los datos sensibles almacenados en la infraestructura de A Team están cifrados en reposo utilizando el estándar AES-256 (Advanced Encryption Standard de 256 bits). Esto incluye:
Datos personales de Clientes y Usuarios almacenados en Cloud SQL (PostgreSQL) y Firestore.
Datos Bancarios: movimientos, saldos y coordenadas financieras almacenadas en Cloud Storage, con cifrado de capa adicional específico para este tipo de dato.
Certificados digitales de los Clientes para emisión de facturas electrónicas vía ARCA, almacenados en celdas seguras de Cloud Storage con cifrado en reposo, cuyas claves privadas de descifrado y credenciales de autenticación asociadas se custodian de forma centralizada en Google Cloud Secret Manager bajo estrictas políticas de IAM.
Datos KYC/KYB en Fase de Activación Financiera: documentos de identidad y datos biométricos almacenados con cifrado AES-256 y políticas de retención mínima.
Credenciales y tokens de acceso: almacenados en formato hash irreversible (bcrypt / Argon2) con sal única por credencial.
El cifrado en reposo se aplica a nivel de volumen (GCP default encryption) y, para datos de mayor sensibilidad, con Customer-Managed Encryption Keys (CMEK) gestionadas en Google Cloud KMS.
2.2 Cifrado en tránsito
Toda comunicación entre componentes de la plataforma y entre la plataforma y sistemas externos utiliza cifrado en tránsito mediante:
TLS 1.2 como mínimo, con preferencia por TLS 1.3, para todas las conexiones HTTPS entre clientes y servidores.
TLS obligatorio para todas las conexiones entre microservicios internos desplegados en Cloud Run.
Conexiones cifradas a bases de datos (Cloud SQL, Firestore) con certificados de cliente gestionados por GCP.
Conexiones a APIs externas (Anthropic, Meta, ARCA, bancos) bajo HTTPS con validación de certificados.
HSTS (HTTP Strict Transport Security) habilitado en todos los dominios públicos de A Team.
2.3 Segregación de Datos Bancarios
Los Datos Bancarios reciben tratamiento de seguridad diferenciado respecto del resto de los datos de la plataforma:
Almacenamiento en buckets de Cloud Storage separados con políticas de IAM exclusivas.
Acceso restringido a los servicios de conciliación únicamente: ningún otro componente de la plataforma puede leer Datos Bancarios directamente.
Logs de auditoría independientes y de mayor granularidad para toda operación sobre Datos Bancarios.
Eliminación segura (secure delete) dentro de los 30 días de terminación del contrato, salvo Legal Hold.
Sin acceso de escritura: los Agentes tienen acceso de solo lectura a Datos Bancarios. Ningún componente de A Team puede iniciar transacciones.
2.1 Encryption at rest
All sensitive data stored in A Team's infrastructure is encrypted at rest using the AES-256 standard (Advanced Encryption Standard, 256 bits). This includes:
Personal data of Clients and Users stored in Cloud SQL (PostgreSQL) and Firestore.
Banking Data: movements, balances, and financial details stored in Cloud Storage, with additional layer encryption specific to this data type.
Client digital certificates for electronic invoice issuance via ARCA, stored in secure Cloud Storage cells with encryption at rest, whose decryption private keys and associated authentication credentials are centrally managed in Google Cloud Secret Manager under strict IAM policies.
KYC/KYB data in Financial Activation Phase: identity documents and biometric data stored with AES-256 encryption and minimum retention policies.
Credentials and access tokens: stored in irreversible hash format (bcrypt / Argon2) with a unique salt per credential.
Encryption at rest is applied at volume level (GCP default encryption) and, for more sensitive data, with Customer-Managed Encryption Keys (CMEK) managed in Google Cloud KMS.
2.2 Encryption in transit
All communication between platform components and between the platform and external systems uses encryption in transit through:
TLS 1.2 as a minimum, with preference for TLS 1.3, for all HTTPS connections between clients and servers.
Mandatory TLS for all connections between internal microservices deployed on Cloud Run.
Encrypted connections to databases (Cloud SQL, Firestore) with client certificates managed by GCP.
Connections to external APIs (Anthropic, Meta, ARCA, banks) under HTTPS with certificate validation.
HSTS (HTTP Strict Transport Security) enabled on all A Team public domains.
2.3 Banking Data Segregation
Banking Data receives differentiated security treatment from the rest of the platform's data:
Storage in separate Cloud Storage buckets with exclusive IAM policies.
Access restricted to reconciliation services only: no other platform component can read Banking Data directly.
Independent audit logs with greater granularity for every operation on Banking Data.
Secure deletion within 30 days of contract termination, unless Legal Hold applies.
No write access: Agents have read-only access to Banking Data. No A Team component can initiate transactions.
3.1 Autenticación multifactor (MFA)
A Team implementa MFA obligatorio en los siguientes contextos:
Todos los accesos administrativos a la infraestructura GCP (Google Cloud Console, APIs de gestión).
Acceso al panel de administración interno de A Team.
Acceso al sistema de escalamiento Chatwoot por parte del equipo operativo.
Acceso a sistemas de gestión de secretos y credenciales.
Los Clientes acceden al Dashboard mediante autenticación de usuario y contraseña con la opción de activar MFA adicional. Se recomienda fuertemente a los Clientes habilitar MFA en sus cuentas.
3.2 Control de acceso basado en roles (RBAC)
A Team implementa un modelo de control de acceso basado en roles (Role-Based Access Control) con los siguientes principios:
Cada miembro del equipo de A Team tiene asignado el rol mínimo necesario para sus funciones específicas.
Los roles se revisan trimestralmente y se ajustan ante cambios de función o baja del empleado/contratista.
Las cuentas de servicio de cada microservicio tienen permisos exclusivos para sus operaciones autorizadas.
El principio de separación de funciones se aplica en operaciones críticas: ningún individuo puede ejecutar y aprobar la misma acción sensible sin un segundo revisor.
Rol Acceso habilitado Restricciones
Agente de IA (AXEL, Datos del caso en curso: Sin acceso a Datos Aníbal) factura, estado, Bancarios completos, sin historial de acceso a datos de otros conversación Clientes, sin capacidad de escritura en registros fiscales
Operador humano Conversación activa Sin acceso a datos de (Chatwoot) escalada, historial del Clientes distintos al caso, datos del Usuario asignado, sin acceso a del caso Datos Bancarios
Desarrollador Entornos de desarrollo y Sin acceso a datos de staging. Datos producción de Clientes anonimizados o reales sintéticos solamente
Administrador de Infraestructura GCP, Acceso a datos de plataforma configuración de producción bajo necesidad servicios justificada y con registro de auditoría
3.3 Gestión de secretos y credenciales
Todas las credenciales, API keys, tokens y certificados se almacenan en Google Cloud Secret Manager, no en código fuente ni variables de entorno no cifradas.
Rotación periódica de credenciales: las API keys de servicios críticos se rotan al menos cada 90 días o ante cualquier sospecha de compromiso.
Prohibición absoluta de hardcoding de credenciales en repositorios de código. Los repositorios son escaneados automáticamente para detectar secretos expuestos.
3.1 Multi-factor authentication (MFA)
A Team implements mandatory MFA in the following contexts:
All administrative access to GCP infrastructure (Google Cloud Console, management APIs).
Access to A Team's internal administration panel.
Access to the Chatwoot escalation system by the operational team.
Access to secrets and credentials management systems.
Clients access the Dashboard through username and password authentication with the option to activate additional MFA. Clients are strongly encouraged to enable MFA on their accounts.
3.2 Role-based access control (RBAC)
A Team implements a Role-Based Access Control model with the following principles:
Each A Team team member is assigned the minimum role necessary for their specific functions.
Roles are reviewed quarterly and adjusted upon changes in function or termination of the employee/contractor.
Each microservice's service accounts have exclusive permissions for their authorized operations.
The principle of segregation of duties applies to critical operations: no individual can execute and approve the same sensitive action without a second reviewer.
Role Enabled access Restrictions
AI Agent (AXEL, Current case data: No access to full Banking Aníbal) invoice, status, Data, no access to other conversation history Clients' data, no write access to tax records
Human operator Active escalated No access to data from (Chatwoot) conversation, case Clients other than the history, case User data assigned one, no access to Banking Data
Developer Development and staging No access to real Client environments. Anonymized production data or synthetic data only
Platform GCP infrastructure, Access to production data administrator service configuration under justified need and with audit record
3.3 Secrets and credentials management
All credentials, API keys, tokens, and certificates are stored in Google Cloud Secret Manager, not in source code or unencrypted environment variables.
Periodic credential rotation: API keys for critical services are rotated at least every 90 days or upon any suspicion of compromise.
Absolute prohibition of credential hardcoding in code repositories. Repositories are automatically scanned to detect exposed secrets.
4.1 Registros de auditoría
A Team mantiene logs de auditoría que registran las siguientes operaciones:
Accesos exitosos y fallidos a la plataforma y a los sistemas administrativos.
Operaciones de lectura, escritura, modificación y eliminación sobre Datos Personales y Datos Bancarios.
Escalamientos activados por Behavioral Guardrails, incluyendo motivo y timestamp.
Acciones de los Agentes en el Tool Use Loop: herramienta ejecutada, parámetros (anonimizados cuando contienen datos sensibles), resultado.
Cambios de configuración del Cliente en el Dashboard.
Solicitudes de exportación o eliminación de datos.
Los logs de auditoría se conservan por un mínimo de doce (12) meses en almacenamiento seguro de acceso restringido. Los logs vinculados a obligaciones legales (Legal Hold) se conservan por los plazos establecidos en el Data Processing Agreement (DPA) vigente en www.the-ateam.ai/legal.
4.2 Monitoreo en tiempo real
GCP Cloud Monitoring y Cloud Logging para alertas automáticas ante anomalías de tráfico, errores críticos y eventos de seguridad.
Behavioral Guardrails: sistema propio de A Team que analiza en tiempo real el volumen, frecuencia y contenido semántico de las comunicaciones de los Agentes para detectar spam, fraude y violaciones a las políticas de Meta. Ver AI Usage Policy vigente en www.the-ateam.ai/legal.
Alertas de detección de intrusiones configuradas para accesos inusuales, intentos de fuerza bruta y patrones de acceso fuera de horario.
Monitoreo de integridad de archivos críticos de configuración.
4.1 Audit records
A Team maintains audit logs recording the following operations:
Successful and failed access to the platform and administrative systems.
Read, write, modification, and deletion operations on Personal Data and Banking Data.
Escalations triggered by Behavioral Guardrails, including reason and timestamp.
Agent actions in the Tool Use Loop: tool executed, parameters (anonymized when containing sensitive data), result.
Client configuration changes in the Dashboard.
Data export or deletion requests.
Audit logs are retained for a minimum of twelve (12) months in secure, access-restricted storage. Logs linked to legal obligations (Legal Hold) are retained for the periods established in the Data Processing Agreement (DPA) in effect at www.the-ateam.ai/legal.
4.2 Real-time monitoring
GCP Cloud Monitoring and Cloud Logging for automatic alerts upon traffic anomalies, critical errors, and security events.
Behavioral Guardrails: A Team's proprietary system that analyzes in real time the volume, frequency, and semantic content of Agent communications to detect spam, fraud, and Meta policy violations. See the AI Usage Policy in effect at www.the-ateam.ai/legal.
Intrusion detection alerts configured for unusual access, brute force attempts, and off-hours access patterns.
Integrity monitoring of critical configuration files.
5.1 Arquitectura cloud (GCP)
A Team opera íntegramente sobre Google Cloud Platform (GCP) región us-east1, aprovechando los controles de seguridad nativos de la plataforma:
VPC (Virtual Private Cloud) con reglas de firewall restrictivas: solo el tráfico necesario para la operación de cada servicio está permitido.
Cloud Run: los Agentes y microservicios se ejecutan en contenedores serverless con aislamiento de entorno de ejecución.
Cloud Armor: protección contra ataques DDoS y Web Application Firewall (WAF) para los endpoints públicos de la plataforma.
Cloud IAM: gestión centralizada de identidades y permisos con políticas de mínimo privilegio.
Binary Authorization: las imágenes de contenedor desplegadas en producción deben estar firmadas y verificadas antes del despliegue.
5.2 Gestión de vulnerabilidades
A Team implementa un programa continuo de gestión de vulnerabilidades:
Escaneo automático de vulnerabilidades en imágenes de contenedor (Artifact Registry Vulnerability Scanning) antes de cada despliegue a producción.
Actualizaciones de seguridad del sistema operativo y dependencias aplicadas dentro de los siete (7) días de publicación de parches críticos (CVSS ≥ 9.0) y dentro de los treinta (30) días para parches de severidad alta (CVSS 7.0--8.9).
Revisión de dependencias de terceros en el código fuente mediante herramientas automatizadas de SCA (Software Composition Analysis).
Pruebas de penetración (pen testing) realizadas por terceros independientes al menos una (1) vez por año.
Programa de divulgación responsable (responsible disclosure): A Team acepta reportes de vulnerabilidades de investigadores de seguridad a través de soporte@the-ateam.ai.
5.3 Backups y recuperación
Backups automáticos diarios de Cloud SQL (PostgreSQL) con retención de treinta (30) días.
Point-in-Time Recovery (PITR) habilitado en las bases de datos críticas, permitiendo recuperación a cualquier punto en los últimos siete (7) días.
Backups de Cloud Storage replicados en una región secundaria de GCP para continuidad ante fallas regionales.
Pruebas de recuperación (restore tests) ejecutadas trimestralmente y documentadas.
RTO (Recovery Time Objective) objetivo: cuatro (4) horas para servicios críticos. RPO (Recovery Point Objective) objetivo: una (1) hora.
5.1 Cloud architecture (GCP)
A Team operates entirely on Google Cloud Platform (GCP) in the us-east1 region, leveraging the platform's native security controls:
VPC (Virtual Private Cloud) with restrictive firewall rules: only the traffic necessary for each service's operation is permitted.
Cloud Run: Agents and microservices run in serverless containers with isolated execution environments.
Cloud Armor: DDoS protection and Web Application Firewall (WAF) for the platform's public endpoints.
Cloud IAM: centralized identity and permission management with least privilege policies.
Binary Authorization: container images deployed to production must be signed and verified before deployment.
5.2 Vulnerability management
A Team implements a continuous vulnerability management program:
Automatic vulnerability scanning of container images (Artifact Registry Vulnerability Scanning) before each production deployment.
Operating system and dependency security updates applied within seven (7) days of publication of critical patches (CVSS ≥ 9.0) and within thirty (30) days for high-severity patches (CVSS 7.0--8.9).
Third-party dependency review in source code through automated SCA (Software Composition Analysis) tools.
Penetration testing (pen testing) conducted by independent third parties at least once (1) per year.
Responsible disclosure program: A Team accepts vulnerability reports from security researchers through soporte@the-ateam.ai.
5.3 Backups and recovery
Automatic daily Cloud SQL (PostgreSQL) backups with thirty (30) day retention.
Point-in-Time Recovery (PITR) enabled on critical databases, allowing recovery to any point in the last seven (7) days.
Cloud Storage backups replicated in a secondary GCP region for continuity against regional failures.
Recovery tests (restore tests) executed quarterly and documented.
Target RTO (Recovery Time Objective): four (4) hours for critical services. Target RPO (Recovery Point Objective): one (1) hour.
Revisión de código (code review) obligatoria antes de todo merge a la rama principal de producción.
Escaneo estático de código (SAST) integrado en el pipeline de CI/CD para detectar vulnerabilidades comunes (OWASP Top 10) antes del despliegue.
Entornos separados para desarrollo, staging y producción, con datos sintéticos o anonimizados en entornos no productivos.
Prohibición de uso de datos reales de Clientes o Usuarios en entornos de desarrollo o pruebas.
Gestión de secretos vía Google Cloud Secret Manager en todos los entornos.
Política de ramas protegidas: los despliegues a producción requieren aprobación de al menos dos revisores.
Mandatory code review before every merge to the main production branch.
Static code scanning (SAST) integrated into the CI/CD pipeline to detect common vulnerabilities (OWASP Top 10) before deployment.
Separate environments for development, staging, and production, with synthetic or anonymized data in non-production environments.
Prohibition of using real Client or User data in development or testing environments.
Secrets management via Google Cloud Secret Manager in all environments.
Protected branch policy: production deployments require approval from at least two reviewers.
7.1 Personal y capacitación
Todo el personal con acceso a datos del Cliente firma acuerdos de confidencialidad antes de iniciar funciones.
Capacitación obligatoria en seguridad de la información y protección de datos al incorporarse y con frecuencia anual.
Proceso formal de offboarding: revocación inmediata de todos los accesos ante baja de un empleado o contratista.
Verificación de antecedentes para roles con acceso a datos sensibles o infraestructura crítica.
7.2 Gestión de proveedores y subprocesadores
Todo subprocesador con acceso a datos del Cliente firma un DPA equivalente al Data Processing Agreement vigente antes de procesar datos.
Revisión anual de cumplimiento de cada subprocesador crítico.
Evaluación de seguridad previa a la incorporación de nuevos subprocesadores: verificación de certificaciones (SOC 2, ISO 27001 o equivalentes) cuando aplique.
Lista actualizada de subprocesadores publicada en la Subprocessor List vigente en www.the-ateam.ai/legal.
7.3 Gestión de dispositivos
Los dispositivos utilizados por el personal de A Team para acceder a sistemas productivos deben contar con cifrado de disco completo habilitado.
Política de pantalla bloqueada automáticamente tras período de inactividad en dispositivos con acceso a sistemas de producción.
Uso de VPN corporativa obligatorio para acceso remoto a sistemas internos.
7.1 Personnel and training
All personnel with access to Client data sign confidentiality agreements before starting their duties.
Mandatory information security and data protection training upon onboarding and annually.
Formal offboarding process: immediate revocation of all access upon termination of an employee or contractor.
Background checks for roles with access to sensitive data or critical infrastructure.
7.2 Provider and sub-processor management
Every sub-processor with access to Client data signs a DPA equivalent to the current Data Processing Agreement before processing data.
Annual compliance review of each critical sub-processor.
Security assessment prior to adding new sub-processors: verification of certifications (SOC 2, ISO 27001, or equivalents) where applicable.
Updated list of sub-processors published in the Subprocessor List in effect at www.the-ateam.ai/legal.
7.3 Device management
Devices used by A Team personnel to access production systems must have full disk encryption enabled.
Policy of automatic screen lock after inactivity period on devices with access to production systems.
Mandatory corporate VPN use for remote access to internal systems.
El protocolo detallado de respuesta ante incidentes de seguridad se establece en la Incident Response Policy del Stack Legal de A Team. Los plazos de notificación ante brechas de seguridad que afecten datos personales son:
Destinatario Plazo máximo Marco normativo
Cliente afectado 72 horas desde GDPR Art. 33 / LGPD conocimiento del Art. 48 / Ley 25.326 incidente
Autoridad regulatoria 72 horas (GDPR); plazo GDPR Art. 33; LGPD; competente local según AAIP Argentina; ANPD jurisdicción Brasil
Titulares de datos Sin demora indebida GDPR Art. 34 / LGPD afectados cuando el incidente Art. 48 / normativas implique alto riesgo equivalentes
A Team no puede garantizar inmunidad absoluta ante incidentes que afecten infraestructura de subprocesadores fuera de su control directo. En estos casos, A Team notificará al Cliente con la información disponible tan pronto como sea posible y colaborará activamente en la investigación.
The detailed security incident response protocol is established in the Incident Response Policy in A Team's Legal Stack. Notification timeframes for security breaches affecting personal data are:
Recipient Maximum timeframe Regulatory framework
Affected Client 72 hours from awareness GDPR Art. 33 / LGPD of the incident Art. 48 / Law 25.326
Competent regulatory 72 hours (GDPR); local GDPR Art. 33; LGPD; authority timeframe per AAIP Argentina; ANPD jurisdiction Brazil
Affected data subjects Without undue delay GDPR Art. 34 / LGPD when the incident Art. 48 / equivalent entails high risk regulations
A Team cannot guarantee absolute immunity against incidents affecting sub-processor infrastructure outside its direct control. In these cases, A Team will notify the Client with the available information as soon as possible and will actively cooperate in the investigation.
Las medidas descritas en esta Política representan el estado actual de los controles de seguridad de A Team. A Team no puede garantizar seguridad absoluta ante amenazas desconocidas, ataques de estado-nación o vulnerabilidades de día cero en infraestructura de terceros.
La responsabilidad total de A Team derivada de incidentes de seguridad está sujeta a los límites establecidos en los Términos y Condiciones y el Data Processing Agreement vigentes en www.the-ateam.ai/legal: máximo tres (3) meses del plan de pago activo o un (1) mes del plan más económico para planes gratuitos.
El Cliente es responsable de la seguridad de sus propias credenciales de acceso, de la configuración adecuada de sus integraciones API y de la seguridad de los sistemas desde los cuales accede a la plataforma de A Team.
The measures described in this Policy represent the current state of A Team's security controls. A Team cannot guarantee absolute security against unknown threats, nation-state attacks, or zero-day vulnerabilities in third-party infrastructure.
A Team's total liability arising from security incidents is subject to the limits established in the Terms and Conditions and the Data Processing Agreement in effect at www.the-ateam.ai/legal: maximum three (3) months of the active paid plan or one (1) month of the most affordable plan for free plans.
The Client is responsible for the security of their own access credentials, the proper configuration of their API integrations, and the security of the systems from which they access A Team's platform.
A Team revisa esta Política al menos una vez por año o ante cambios materiales en la infraestructura, los marcos normativos aplicables o el perfil de riesgo de la plataforma. Las actualizaciones materiales se notificarán al Cliente con al menos quince (15) días corridos de anticipación.
Contacto para consultas de seguridad: soporte@the-ateam.ai
Contacto legal: legal@the-ateam.ai
--- FIN DEL DOCUMENTO ---
A Team Agency LLC -- Documento de uso público. www.the-ateam.ai/legal
Security Policy v1.0 -- Junio 2026
A Team reviews this Policy at least once per year or upon material changes in infrastructure, applicable regulatory frameworks, or the platform's risk profile. Material updates will be notified to the Client with at least fifteen (15) calendar days' advance notice.
Contact for security inquiries: soporte@the-ateam.ai
Legal contact: legal@the-ateam.ai
--- END OF DOCUMENT ---
A Team Agency LLC -- Public document. www.the-ateam.ai/legal
Security Policy v1.0 -- June 2026