Security Checklist: What to Verify Before Connecting Tools to Your AI Stack

Access Scopes: Least Privilege by Default

When an AI agent connects to a third-party tool, it authenticates via OAuth 2.0, an API key, or a service account. The scope of that authentication determines what the agent can read, write, and delete. Requesting broader permissions than necessary is the most common vector for large blast-radius incidents when credentials are compromised.

Common failure modes

• Requesting admin scope when read:contacts is sufficient
• Using a developer’s personal OAuth token in production
• Sharing a single service account key across multiple automation pipelines
• Granting workspace-level access instead of resource-level access

What to verify

• OAuth scope is the minimum required for the workflow — not the maximum the tool allows
• Service accounts are dedicated per pipeline, not shared across automations
• Credentials are scoped to specific resources (specific folders, tables, or channels)
• Token expiration is configured and refresh logic is implemented in the pipeline code
• Access grants are reviewed and re-approved at least quarterly

Secrets Management: No Plaintext, No Exceptions

API keys, OAuth tokens, webhook signing secrets, and database passwords must never appear as plaintext in source code, configuration files, or environment variables committed to version control. This is a non-negotiable baseline, but teams continue to violate it — most often under deadline pressure with an intent to “fix it later”.

What to verify

• All secrets are stored in a managed secrets vault (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, or Azure Key Vault)
• .env files are in .gitignore and have never been committed — run a git history scan to confirm
• Secrets are rotated at least every 90 days, and immediately when a team member with access departs
• A secrets scanner (truffleHog, git-secrets, or GitHub Advanced Security) runs on every pull request
• Secrets are injected at runtime, not hardcoded in Docker images or pipeline manifests
• No credentials appear in application logs, error messages, or monitoring dashboards

Audit Logging: What You Must Capture

For an AI automation pipeline to be auditable, every action taken by every agent must be logged with enough context to reconstruct what happened, when, and with what inputs. Logs that only record success/failure counts are insufficient for compliance audits and useless for incident investigations.

What to log

• Every external API call: endpoint, HTTP method, timestamp, response code, and latency
• Every data write: what record was created, updated, or deleted — by which workflow, with what trigger
• Every LLM inference call: model version, prompt hash (not the full prompt if it contains PII), output classification
• All authentication events: successful and failed token exchanges, with source IP
• Any data access event involving PII, financial records, or health data

What to verify

• Logs are shipped to a centralised SIEM or log aggregation system — not stored only on the workflow runner
• Log integrity is protected: logs cannot be deleted by the same service account that generated them
• Logs are searchable for at least 12 months (required by most compliance frameworks)
• An alert fires on repeated authentication failures or anomalous API call volumes
• Log schema is documented so any team member can interpret entries without domain knowledge

Data Retention: What You Must Purge

AI pipelines are data-hungry. They ingest, transform, and store intermediate data across multiple stages. Without explicit retention policies, PII and sensitive business data accumulates indefinitely in staging tables, message queues, and workflow execution logs. Most teams only discover this during a GDPR audit — by which point the data has been sitting unmanaged for months.

What to verify

• Temporary staging tables have a TTL (time-to-live) — default to a 30-day maximum
• Message queue payloads containing PII are purged after successful processing, not retained in dead-letter queues indefinitely
• Workflow execution history does not store full input/output payloads — only sanitised summaries and record IDs
• AI memory stores (vector databases, conversation history) have explicit retention limits per user or session
• GDPR/CCPA deletion requests trigger automated purges across all pipeline stages — not just the primary database

Sensitive Data Flow Mapping: Where Data Is Allowed to Go

Before any integration goes live, produce a data flow diagram that shows every system that will receive, process, or store data from the integration. Then verify that data is not flowing to systems not authorised to receive it. This is the step most often skipped under time pressure — and the one regulators check first.

What to verify

• A written data flow diagram exists for the integration and has been reviewed by a second engineer
• Third-party tools that receive data are listed in your privacy policy and Data Processing Agreement (DPA)
• No PII is sent to LLM providers unless your contract includes a signed DPA with explicit opt-out from training data usage
• Cross-border data transfer restrictions are respected — EU PII must not be processed on US-only infrastructure without Standard Contractual Clauses
• Encryption in transit: all API calls use TLS 1.2 or higher — older protocols are blocked at the network level
• Encryption at rest: all databases and storage buckets are encrypted with keys you control (customer-managed, not provider-default)

Pre-Launch Sign-Off Checklist

Use this as a final deployment gate. Every item must be confirmed before an integration goes to production.

Conclusion

Connecting tools to an AI stack without completing these checks is not just a security risk — it is a liability risk. Regulators are increasingly auditing AI data pipelines, and the checklist above maps to specific requirements in GDPR Article 30, SOC 2 CC6 (logical access controls), and ISO 27001 Annex A.

The most common failure we see at AtomLeap is not malicious intent — it is speed. Teams move fast, skip the service account setup, and put a developer’s personal OAuth token into production. That token often has admin-level access to the entire workspace. When the developer leaves, the pipeline breaks. When the token is compromised, the blast radius is the entire organisation.

Build this checklist into your deployment workflow. It takes 30 minutes to complete. A breach takes months — and often hundreds of thousands of pounds — to recover from.