> ## Documentation Index > Fetch the complete documentation index at: https://docs.anomalyarmor.ai/llms.txt > Use this file to discover all available pages before exploring further. # Data Handling > What data AnomalyArmor accesses and how we protect it The most common security question: "What data does AnomalyArmor actually see?" Here's the complete answer. ## What We Access AnomalyArmor queries **metadata and aggregate statistics only**, never your actual row data. Every query is validated by our open-source [Query Gateway](/security/query-gateway) before execution. | We Access | We Never Access | | -------------------------- | ------------------------ | | Table names | Row data | | Column names | Actual values in columns | | Data types | PII content | | Timestamps (for freshness) | Query results | | Row counts | Business-sensitive data | | Constraint definitions | File contents | ### The Queries We Run During discovery, we query system catalogs: ```sql theme={null} -- PostgreSQL example SELECT table_name, column_name, data_type FROM information_schema.columns WHERE table_schema NOT IN ('pg_catalog', 'information_schema'); -- For freshness, we query MAX of timestamp columns SELECT MAX(updated_at) FROM your_table; ``` We **never** run: ```sql theme={null} SELECT * FROM your_table; -- ❌ Never SELECT email FROM users; -- ❌ Never ``` ### Freshness Monitoring For freshness checks, we query the maximum value of your designated timestamp column: ```sql theme={null} SELECT MAX(created_at) FROM orders; -- Returns: 2024-01-15 08:30:00 -- We see: "Last update was 30 minutes ago" -- We don't see: Any actual order data ``` ## Data Storage ### What We Store | Data Type | Location | Encryption | Retention | | -------------------- | --------------- | ----------- | ---------------- | | Database credentials | AWS (encrypted) | AES-256-GCM | Until you delete | | Schema metadata | AWS RDS | AES-256 | Account lifetime | | Change history | AWS RDS | AES-256 | 90 days | | Audit logs | AWS S3 | AES-256 | 1 year | ### What We Don't Store * Your actual data values * Query results beyond metadata * Copies of your database ## Data Flow Data flow showing TLS 1.3 connection from your database to AnomalyArmor with encrypted storage

Data flow showing TLS 1.3 connection from your database to AnomalyArmor with encrypted storage

1. Discovery engine connects via TLS 1.3 2. Runs metadata queries against system catalogs 3. Receives only schema information 4. Stores encrypted in our infrastructure 5. Your actual data never leaves your database ## Compliance Implications ### For GDPR * We don't process personal data (only metadata) * DPA available if required * Data deletion on account closure ### For HIPAA * No PHI accessed * BAA available for healthcare customers * Enhanced audit logging available ## Verification Want to verify what we access? You have multiple options: ### Check Your Database Logs ```sql theme={null} -- PostgreSQL: Enable query logging ALTER SYSTEM SET log_statement = 'all'; SELECT pg_reload_conf(); -- Filter for AnomalyArmor user grep 'anomalyarmor' /var/log/postgresql/postgresql.log ``` You'll see only `information_schema` queries and timestamp aggregations. ### Audit the Query Gateway Our [Query Gateway](https://github.com/anomalyarmor/anomalyarmor-query-gateway) is open source. Your security team can: 1. Review the source code 2. Run the 97+ security tests 3. Verify exactly which queries are allowed at each access level No. We can't see your data because we never access it. Support staff can see metadata (table names, column names) to help troubleshoot, but never actual data values. We see the column name "password" exists and its data type (e.g., varchar). We never see the actual password values stored in that column. 1. Audit our open-source [Query Gateway](https://github.com/anomalyarmor/anomalyarmor-query-gateway) 2. Check your database query logs 3. Use a read-only database user with only `SELECT` on system catalogs 4. Run a network packet capture during discovery ### Does AnomalyArmor ever read the actual values stored in my tables? No. Every query is restricted to system catalogs and bounded aggregates (`COUNT`, `MAX`, `MIN`, `AVG`, `SUM`). Raw reads like `SELECT *` or `SELECT email FROM users` are blocked by the open-source [Query Gateway](/security/query-gateway) before they ever reach your database. ### If I have a PII column like 'ssn' or 'email', what does AnomalyArmor see? We see the column name and its data type. We do not see a single row of the column's contents. Column names help auto-classify sensitivity, but the values never leave your database. ### Exactly which SQL statements does AnomalyArmor run against my database? Metadata queries against `information_schema` and `pg_catalog` for structure, plus aggregate queries like `SELECT MAX(updated_at) FROM your_table` for freshness. See the [queries we run](#the-queries-we-run) section above for concrete examples. ### How can I independently verify what AnomalyArmor queries? Turn on query logging for the `anomalyarmor` user and audit the logs, or run a packet capture during discovery. The [Query Gateway](https://github.com/anomalyarmor/anomalyarmor-query-gateway) is open source with 97+ security tests you can run yourself. See [Verification](#verification) above. ### Can AnomalyArmor employees see my data? No. We can't see your data because we never access it. Support staff can see metadata (table and column names) to help troubleshoot, but never actual values. Every credential access is logged. ### Does AnomalyArmor store copies of my tables? No. We store schema metadata (table and column names, types, constraints), change history, and timestamp aggregates, not the underlying rows. See [What We Store](#what-we-store) for the full list with encryption and retention details. ## See Also Open-source SQL security layer Full security documentation How long we keep data