Agentic AI Governance: Mitigating Liability and Protecting Information Assets
The model decided to do that” is not a legal defense
The previous post in this series covered agent security controls — tool scoping, separating decision from execution, memory hygiene, egress control. That’s the engineering layer. This post is about the layer above it, the one a board, an insurer, a regulator, or opposing counsel will actually examine.
The reframe that matters is simple and unforgiving: an action taken by your agent is an action taken by your organization. There is no legal or contractual construct in which “the model decided to do that” reduces your exposure. Autonomy distributes execution. It does not distribute liability.
So the two questions this post answers are the ones I’d want answered before signing off on any agent going to production:
- If this agent does something harmful, where does the liability land and what reduces it?
- What information assets can this agent reach, and what stops them leaving?
Why agents invert the asset protection model
For thirty years, information security has been organised around keeping unauthorised actors away from assets. Perimeters, access control, segmentation, DLP — all of it assumes the adversary is unauthorised.
An agent is authorised. It holds legitimate credentials, calls sanctioned APIs, reads permitted repositories, and does so at machine speed. When an agent exfiltrates data, no access control was violated. The agent used exactly the permissions you gave it, in a sequence you didn’t anticipate, because its context was partly written by someone else.
That’s why the operating principle from the OWASP Agentic Security Initiative work is agency as the security boundary. An agent is not trustworthy because its underlying model is trustworthy. Trust attaches to what the agent is permitted to do, not to what produced its intentions.
Which yields a principle most organisations don’t have yet, distinct from least privilege:
Least agency — give an agent only the autonomy required for the business objective, separately from minimising its permissions.
An agent can be perfectly least-privileged and still over-agentic: narrow permissions, but authority to act on them without validation. Both dials need setting.
Where the liability actually lands
Four distinct channels, and they don’t behave the same way.
Contractual. This is the nearest-term exposure and the one most organisations walk into unknowingly. Your customer DPAs, MSAs, security addenda, and — critically — your completed vendor security questionnaires are representations. If you answered “all access to customer data is logged and reviewed” before deploying an agent that reads customer data through a service account with no per-action logging, that answer is now inaccurate. Vendor questionnaire responses are the most commonly overlooked liability surface in agent deployment, because nobody re-reads them when architecture changes.
Regulatory. Under the EU AI Act, deployers of high-risk systems carry direct obligations under Article 26 — ensure staff competence, monitor operation, notify incidents, retain logs for at least six months, inform affected workers — and Article 14 requires human oversight that constitutes a demonstrated capability to intervene, interrupt, and disregard. Under GDPR and CCPA/CPRA you remain the controller regardless of how autonomous the processing became. California’s ADMT rules add risk-assessment and notice obligations where agents contribute to significant decisions.
Negligence and standard of care. This one is slower-moving and more consequential. OWASP’s agentic guidance, ISO/IEC 42001, and the NIST AI RMF are converging into a recognised reference standard for reasonable practice. Once a documented, freely available standard exists, failing to implement its obvious provisions becomes evidence of a failure to meet the standard of care. “We didn’t know agents could be prompt-injected” stopped being credible some time in 2025.
Supply chain and value chain. Your model provider’s terms limit their liability; they do not transfer yours. If an agent harms your customer, your customer sues you. ISO 42001’s A.10.3 is specifically about allocating responsibilities across the AI value chain — and the allocation you write down is the one you’ll be held to. Read your provider terms for what they don’t cover.
The practical implication: liability mitigation is not primarily about preventing incidents. It’s about being able to demonstrate that you exercised reasonable care, in writing, before the incident. Which is an evidence problem, not a security problem.
Risk tiering: the one artifact that makes the rest tractable
Most agent governance fails because it tries to apply uniform controls to non-uniform risk. Tier first, then control proportionally. Four tiers, and the tier drives who signs and what’s mandatory.
| Tier | Definition | Typical examples | Mandatory controls | Approval authority |
|---|---|---|---|---|
| 1 — Assistive | Produces information or recommendations; cannot independently execute consequential actions | Drafting, summarisation, low-risk analysis | Inventory, owner, acceptable use, basic logging | Team lead |
| 2 — Controlled action | Executes reversible or low-impact actions under bounded permissions | Ticket creation, sandbox changes, non-sensitive workflow automation | Tier 1 plus tool allowlist, scoped credentials, action logging, rollback | Engineering owner + security review |
| 3 — Privileged autonomous | Reaches sensitive data, privileged systems, financial workflows, production infrastructure, security controls, or multiple enterprise systems | Data-room permission management, production incident remediation, financial reconciliation | Strong unique identity, least privilege, independent action authorisation, comprehensive logging, behavioural monitoring, adversarial testing, tested rollback and kill switch, formal risk acceptance | Named executive risk owner |
| 4 — High-impact / safety-critical | Materially affects legal rights, safety, critical infrastructure, regulated decisions, major financial outcomes, or irreversible operations | Credit or eligibility decisions, payment initiation, regulated disclosure, security control modification | Tier 3 plus human approval for consequential actions, independent policy enforcement, segregation of duties, formal TEVV, documented residual-risk acceptance, tested emergency shutdown | Executive + documented board or committee awareness |
Two notes from applying this. Tier assignment should be based on maximum action impact, not typical action impact — an agent that files tickets 99% of the time and can delete a production table 1% of the time is a Tier 3 agent. And anything unclassified defaults to the higher tier, not the lower one; ambiguity is not an argument for less control.
Use a plain 5×5 likelihood × impact model, and raise the impact rating whenever the agent can access regulated data, reach production, move money, modify security controls, affect legal or rights outcomes, execute code, control physical systems, or propagate actions to other agents.
Deployment gates: turning governance into a decision
An agent should not reach production until seven gates pass. This is the mechanism that converts principles into a defensible record, and it’s the thing to build first because everything else hangs off it.
| Gate | What it establishes | Owner |
|---|---|---|
| 1 — Inventory | Agent identified, owner assigned, business purpose documented, risk tier assigned | AI governance owner |
| 2 — Architecture | Data flows, trust boundaries, tool inventory, identity model, memory model, external dependencies documented | Technical owner |
| 3 — Authorisation | Least privilege implemented, tool permissions reviewed, credentials scoped, high-impact actions protected, human approval defined | Security + IAM |
| 4 — Security testing | Goal hijack, tool misuse, privilege abuse, supply chain, code execution, memory poisoning, inter-agent, cascade, human-trust, and rogue-agent testing performed | Security testing owner |
| 5 — Monitoring | Agent activity, tool calls, identity events, and policy decisions logged; anomalies monitored; alerts configured | SecOps |
| 6 — Recovery | Kill switch, rollback, credential revocation, and incident response procedure each tested, recovery owner assigned | SecOps + engineering |
| 7 — Governance | Risk assessments approved, ISO 42001 and NIST AI RMF crosswalks completed, residual risk accepted, evidence package complete | Risk owner |
Gate 6 is where I see the most theatre. A kill switch that exists in a runbook and has never been executed is not a control — it’s an assumption. Test it, record the test, and record how long it took.
The output of the gate process should be one explicit disposition, not a vague sign-off: approved, approved with conditions, restricted, remediate before deployment, rejected, or suspended — each with the risk tier, material findings, residual risk, required controls, control owners, approval authority, and an expiry date. Approvals without expiry dates decay into permanent permission.
Prohibited design patterns
The fastest way to raise the floor across an organisation is a short list of patterns that are critical findings unless explicitly justified and formally risk-accepted:
- Unrestricted shell, filesystem, or internet access
- Shared administrator credentials, or long-lived unrestricted tokens
- Model output alone authorising a privileged action
- Autonomous modification of security controls, or autonomous credential creation
- Unvalidated dynamic tool loading; untrusted MCP servers in privileged workflows
- Untrusted agent-to-agent delegation
- Persistent memory without provenance or lifecycle control
- Production access without rollback; no tested kill switch for high-impact agents
- An agent approving its own high-impact action
- An agent controlling its own security monitoring
Those last two deserve their own sentence. They are segregation of duties, restated for non-human actors. We have decades of consensus that the person who initiates a payment shouldn’t approve it, and that administrators shouldn’t be able to edit the logs that record their activity. Both principles apply unchanged to agents, and both are routinely violated in agent architectures because the agent is convenient and the separation is friction. If you write one governance rule this quarter, write that one.
The corollary for incident response: do not rely on the compromised agent to determine whether it is compromised. Detection, containment, and forensics must sit outside the agent’s own execution path — which is also why monitoring at the syscall, network, and identity layers beats monitoring the agent’s self-reported activity.
Protecting the information assets specifically
Agents create asset classes your data inventory probably doesn’t cover.
Agent memory is a data store. It holds fragments of everything the agent has processed, usually with no classification, no retention schedule, and no owner. It needs all three. Memory also needs provenance — you should be able to say where an entry came from and whether the source was trusted — plus TTLs, write authorisation, quarantine, and rollback.
Deletion rights now reach further than most programs realise. A GDPR erasure request or a CCPA deletion request has to propagate to agent memory, conversation state, vector embeddings, and cached retrieval indices. Embeddings derived from personal data are still personal data. Most deletion pipelines were built before any of these stores existed, and I’d treat “can we actually delete from the vector store and the agent’s memory” as a question to answer before the first request arrives rather than during the response window.
Prompts and system instructions are assets. They encode business logic, control boundaries, and sometimes proprietary process knowledge. They’re also a target — extraction gives an attacker your control design. Version them, restrict who can change them, and treat a prompt change as a change requiring reassessment.
Audit evidence is an asset. The logs proving your controls operated are what stand between you and an adverse inference. They need integrity protection and retention aligned to the longest applicable requirement — for EU high-risk deployers, at least six months under Article 26, though contractual and litigation-hold needs often run longer.
And on classification: the agent’s context window should be governed by your data classification scheme, not by whatever the retrieval layer happened to return. Restricted data should be redacted before entering context, not filtered on the way out.
Controls are not effective because they exist
A rating scale worth adopting verbatim, because it forces honesty. Rate every agent control from 0 to 5: 0 not implemented, 1 ad hoc, 2 partially implemented, 3 defined, 4 implemented and evidenced, 5 measured, tested, and continuously improved.
Most organisations sit at 3 and report 4. The gap between “defined” and “evidenced” is exactly where audit findings live. A control should not be rated effective merely because a policy exists.
One crosswalk caution, since I do this work for a living and see it done badly: do not claim an ISO 42001 control is satisfied because an OWASP mitigation is in place. They’re different instruments. OWASP ASI gives you agent-specific threat identification and testing; 42001 gives you management-system accountability, documented process, risk treatment, and continual improvement; the NIST AI RMF gives you the GOVERN / MAP / MEASURE / MANAGE lifecycle. Record an explicit crosswalk with the applicability decision, implementation status, owner, and evidence for each — not a mapping table asserting equivalence. An auditor will test the claim, not the table.
Monitoring and reassessment triggers
Track as security KPIs: denied and unauthorised tool calls, privilege-escalation attempts, prompt-injection detections, policy violations, anomalous actions, credential misuse, exfiltration attempts, memory-integrity violations, and inter-agent authentication failures.
Track as risk indicators — these are leading, and they’re the ones governance functions miss: agent permission growth, new tools and connectors, model version changes, prompt changes, skill changes, MCP or A2A changes, new memory sources, new data classifications entering scope, and new autonomy levels.
Reassess on any of: model change, major prompt change, tool or permission change, new external agent or MCP connection, material architecture change, new sensitive data in scope, new regulatory requirement, security incident, or significant behavioural drift. Note that most of those are routine engineering events, which is why annual review cycles don’t work for agents. Tie reassessment to change control, not to the calendar.
From the practitioner’s chair
Two things I’d emphasise from having done this rather than read about it.
When I led ShareVault — a virtual data room platform serving M&A and financial services clients — through ISO 42001 Stage 2 certification on the first attempt, and later served as internal auditor, the recurring lesson was that controls were almost never the failure point. Evidence was. The organisations that struggle aren’t the ones without controls; they’re the ones that can’t produce the artifact showing a control operated on a specific date under a specific policy version.
And when I audited that organisation’s MCP Governance Standard and produced a v1.1 redline with 27 changes — covering OAuth 2.1 with PKCE, token audience validation, SSRF and egress controls, tool manifest integrity, and confused-deputy protections — the pattern across nearly all of them was one idea: authority must be bound to a specific action rather than held ambiently by a component. An unaudienced token is authority without a destination. An unverified tool manifest is authority without a definition. A confused-deputy gap is authority without a requester. Liability follows unbound authority with remarkable consistency.
What to do in the next 90 days
- Inventory the agents, including the ones nobody registered. You cannot govern, tier, or defend what isn’t listed. Expect to find more than you think, particularly agent features embedded in tools you already buy.
- Tier them by maximum action impact and identify every Tier 3 and Tier 4 agent. Those get attention first; the rest can wait.
- Re-read your customer commitments and your last three vendor questionnaire responses against what your agents can now actually do. Fix the inaccurate answers before a customer finds them.
- Publish the prohibited-patterns list as policy, and require a named risk acceptance for any exception.
- Test one kill switch end to end and write down how long it took. That single artifact will tell you more about your real posture than any maturity assessment.
- Stand up the gate process and route the next agent through it. The first one is slow; the fifth is routine.
The organisations that come through the next two years cleanly won’t be the ones that avoided agent incidents. They’ll be the ones who can show a documented risk decision, made by a named person, on a dated record, with the evidence that the controls they claimed were operating actually were.
Work with DISC InfoSec
DISC InfoSec helps B2B SaaS and financial services organisations deploy agentic AI that survives both an attacker and an auditor: agent discovery and inventory, risk tiering, OWASP ASI assessment, MCP and tool-permission review, deployment gate design, human oversight architecture, and the evidence packages that map to ISO/IEC 42001, NIST AI RMF, and EU AI Act Articles 14 and 26.
We led VDR organization through ISO 42001 Stage 2 certification on the first audit attempt as the internal practitioner, served as internal auditor, and authored their MCP Governance Standard. If you have agents in production and no dated record of who accepted the risk, that’s the assessment to run now.
DISC InfoSec — Principal Consultant, DISC InfoSec (Deura Information Security Consulting LLC), Petaluma, CA CISSP, CISM | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner
📅 calendly.com/hd-deurainfosec 📧 infodeurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com
This post is security and governance guidance, not legal advice. Liability allocation and regulatory scope should be confirmed with counsel.
Frameworks and references
- OWASP Agentic Security Initiative; OWASP Top 10 for Agentic Applications; OWASP Agentic AI Threats and Mitigations; OWASP AI Agent Security Cheat Sheet
- ISO/IEC 42001:2023 — Clauses 4–10; Annex A control themes including AI policy, impact assessment, lifecycle, data management, responsible use, third-party relationships, logging and monitoring, incident management
- NIST AI RMF 1.0 (NIST AI 100-1); NIST AI 600-1 Generative AI Profile
- Regulation (EU) 2024/1689 (EU AI Act), Arts. 14, 26
- CCPA/CPRA and CPPA ADMT regulations; GDPR Arts. 17, 24, 28, 32
- Thirty years of security assumed the attacker was unauthorized – Your agent isn’t
- Frontier Model, Familiar Framework: Reading Fable 5’s Guardrails Through ISO 42001
- ISO 42001 Evidence Checklist: What Auditors Actually Look For (2026)
- Agents don’t produce wrong answers anymore They take wrong actions – A practitioner’s guide to agent security
- AI Governance for Bay Area Startups: What to Put in Place Before Enterprise Customers Ask
