Deploying AI agents inside an organization is no longer just an engineering decision — it is a compliance decision. An agent that reads documents, invokes APIs, writes to databases, and communicates with other agents touches nearly every control domain your auditors care about. The checklist below is organized by domain: each item is a concrete question you should be able to answer, not a vague objective. If you are still mapping your overall obligations, What Is AI Agent Governance? is a useful starting point before working through the items below.

Identity and Access Controls

The first question any auditor asks is: who can do what, and how do you know?

Can you enumerate every principal that has access to your AI platform? That includes human operators, service accounts, agents themselves, and MCP (Model Context Protocol) servers. If you cannot produce that list on demand, your access posture is opaque.

Are human accounts protected by multi-factor authentication? Operators who can reconfigure agents, adjust budgets, or read audit logs represent a high-value target. TOTP-based MFA — or better, phishing-resistant passkeys — should be required for these roles, not optional.

Is access provisioned and deprovisioned via your identity provider? Manual account management creates orphaned accounts. SCIM 2.0 provisioning tied to your IdP (Okta, Azure AD, Google Workspace) ensures that when someone leaves, their access to your AI tooling is revoked automatically, not in a quarterly cleanup script.

Are agent identities distinct from human identities? An agent authenticating with a shared service-account password is indistinguishable from a human and immune to behavioral anomaly detection. Agents should carry their own credentials — ideally short-lived or rotatable — so their activity is attributable and their blast radius bounded.

Is role-based access control enforced at every API call? Broad "admin" roles granted for convenience become a liability. Fine-grained permissions — who can view vs. manage vs. delete — must be enforced server-side, not just in the UI.

Audit Logging and Evidence

Compliance without evidence is just intent.

Do you have an immutable audit log of every significant action? Agent task execution, configuration changes, access-policy updates, and billing events should all produce a timestamped, attributable record. "Immutable" means the log itself cannot be silently modified — cryptographic integrity checks or append-only storage are the common mechanisms. See Tamper-Evident Audit Logs with Cryptographic Proofs for the technical patterns behind this control.

Can you produce audit evidence for a specific control on short notice? Frameworks like SOC 2, ISO 27001, NIST AI RMF, and ISO 42001 require you to demonstrate that controls were operating over a defined period. If gathering that evidence involves manually querying databases and stitching together spreadsheets, the cost of your next audit is high and the reliability of your evidence is low.

Is your log retention policy documented and enforced? Regulators often specify minimum retention windows — commonly one to three years. Your retention policy should be explicit, applied consistently, and visible to your compliance team, not buried in infrastructure configuration.

Do security events generate alerts, not just log entries? A log that nobody reads is not a control. Anomalous authentication attempts, unexpected agent behaviors, and access-policy violations should surface as reviewable events, not disappear into a log aggregator.

Data Subject Rights and GDPR

If your agents process personal data — and most do — Article 17 of the GDPR creates an obligation you cannot ignore.

Can you identify all personal data associated with a specific data subject? Agents tend to scatter PII across task outputs, logs, and conversation histories. Before you can honor an erasure request, you need to know where the data lives.

Do you have a documented and tested erasure procedure? "Tested" is the operative word. An erasure procedure that has never been exercised is not a control. The procedure should cover what data is deleted, what is anonymized, what is retained for legal hold, and how you confirm completion.

Is erasure applied to derived records, not just primary storage? Deleting a user's profile row while leaving personal data in agent task outputs and authentication events does not satisfy the regulation's intent. Cascading erasure — including event logs that contain PII — needs explicit design.

Do you have records of consent and processing basis? For agents that process personal data, you need to demonstrate the lawful basis and, where applicable, maintain consent records that are themselves subject to erasure.

Are cross-border data transfers documented? If your agents or AI providers process data outside the EU/EEA, you need appropriate transfer mechanisms (SCCs, adequacy decisions, BCRs) and records to demonstrate them.

EU AI Act Risk Classification

The EU AI Act introduces a risk-tiered framework that applies to AI systems, including agentic ones. The classification your agents fall into determines your obligations.

Have you classified each agent by risk tier? The Act distinguishes unacceptable risk (prohibited), high risk (significant obligations), limited risk (transparency requirements), and minimal risk (light touch). Agents that make consequential decisions about people — hiring, credit, access to services, law enforcement — are likely high-risk. Agents that summarize documents or draft emails are probably minimal or limited risk. For a deeper breakdown of what the Act requires in practice, see The EU AI Act Explained for Engineering Teams.

Are your high-risk agents registered in the EU database? Providers of high-risk AI systems in scope of the Act must register their systems in an EU-maintained database. Check whether your organization falls under the provider or deployer definition — the obligations differ.

Do you have a conformity assessment process for high-risk systems? High-risk AI systems require documented conformity assessments before deployment, covering training data governance, human oversight, accuracy and robustness, and cybersecurity. This applies again when systems are substantially modified.

Is human oversight embedded in high-risk agent workflows? The Act requires that high-risk AI systems are designed to allow human oversight and intervention. "Human in the loop" should be an architectural requirement for these systems, not an afterthought.

Are you monitoring for post-deployment drift? Classification at deployment time is not sufficient. If an agent's behavior or use case evolves, its risk classification may change. Periodic reassessment should be part of your operational process.

Vendor and MCP Server Due Diligence

Your compliance posture extends to the services your agents depend on.

Have you assessed the AI providers your agents call? When an agent sends data to an LLM API, that data leaves your perimeter. You need to know: what is the provider's data retention policy? Do they train on your data by default? Do they have a data processing agreement (DPA)? Are they processing in a jurisdiction consistent with your obligations?

Have you inventoried every MCP server your agents connect to? MCP servers extend agent capabilities — they are, in effect, privileged tools with access to external systems. An unvetted MCP server is an untrusted extension of your agent's attack surface. Maintain an inventory, assess each server's trust level, and apply least-privilege.

Do third-party integrations have documented data flows? For each external system an agent integrates with, document what data flows in and out, the retention policy on each side, and the contractual basis.

Common questions

Is there a single framework that covers everything here?

No single framework covers all of it. ISO 42001 (AI management systems) and NIST AI RMF address AI-specific governance. SOC 2 and ISO 27001 cover general information security controls. GDPR covers personal data. The EU AI Act adds risk-tier obligations. Most organizations working with agentic AI will need to operate across at least two or three of these simultaneously. The practical approach is to map controls once and reuse evidence across frameworks rather than running separate compliance programs for each.

How does Praesidia help with this checklist?

Praesidia is designed to address the infrastructure layer of this checklist: identity and RBAC for all principal types (users, agents, MCP servers), cryptographically signed audit logs, data retention policy management, GDPR erasure with cascading PII deletion, per-agent EU AI Act risk classification and compliance tracking, and evidence collection tied to specific framework controls. The platform documentation covers each of these capabilities in detail. It does not replace your legal analysis, your DPO's judgment on processing basis, or your conformity assessments — those require human expertise specific to your use case.

How often should this checklist be revisited?

At minimum, annually, and triggered by any of: a significant change to your agent architecture or data flows, a new regulatory development (the EU AI Act implementation timeline has continued to evolve), a security incident, or a new vendor relationship. Compliance is not a point-in-time certification — it is an ongoing operational discipline.

Putting the Checklist to Work

The items above are not equally urgent for every organization. Start by identifying your highest-risk agents — those that handle personal data, make consequential decisions, or have access to sensitive systems — and work through the identity, audit, and GDPR sections for those first. Then expand to the EU AI Act classification exercise for each agent in your portfolio.

For vendor due diligence, an inventory is the prerequisite. If you do not know what external services your agents are calling, you cannot assess them. Instrument your platform to surface that information before trying to evaluate it.

Compliance work tends to surface architectural gaps that were invisible during development. Done early enough, it shapes system design in ways that make ongoing operation cheaper and audits less painful. The organizations that treat AI agent compliance as an afterthought are the ones who discover — in the middle of an audit — that they have no way to honor an erasure request or produce evidence that a control was operating six months ago. Start with the questions you cannot currently answer; those are your highest-priority gaps.