Do emerging AI governance proposals create a workable chain of responsibility for detecting and stopping harmful behavior after deployment?

My position is a qualified yes: emerging governance supplies workable components of post-deployment responsibility when joined to cybersecurity duties, although not yet universal coverage. Responsibility should follow operational control: operators lead detection and containment; customers revoke delegated permissions; infrastructure and model-service providers intervene when operators cannot contain harm.

For this argument, an AI agent is software using a model to select and execute actions through tools. Prompt injection means attacker-supplied content redirecting model instructions; model alignment means conformity to intended behavioral constraints. Pre-deployment evaluation tests before release; incident reporting communicates qualifying failures afterward.

First, actual intervention demonstrates that containment need not await a universal model-level switch. Anthropic’s November 2025 technical report describes a campaign targeting roughly 30 entities, with a handful of successful intrusions. After detection, it banned identified accounts over a ten-day investigation and notified affected entities as appropriate. This was malicious operator-directed misuse involving credential harvesting—not evidence of a model independently choosing espionage. These are vendor-reported findings, not independently audited results; account bans demonstrate a concrete intervention, not proof that all attacker activity stopped. (assets.anthropic.com)

EchoLeak supplies a different test: the published case study describes a crafted email inducing Microsoft 365 Copilot to exfiltrate information through prompt injection and application-security bypasses. That demonstrates a vulnerability, not independently established victim losses. My inference is that containment must address the application’s data and network pathways, rather than treating every failure as model misalignment. (arxiv.org)

Second, governance extends beyond pre-release testing. The EU AI Act’s Article 72 requires lifetime monitoring for covered high-risk systems; Article 26(5) requires deployers to notify relevant parties and suspend use when its specified risk condition arises. Article 55 requires systemic-risk general-purpose model providers to track and report serious incidents without undue delay. Article 93 authorizes Commission requests for restriction, withdrawal or recall. These are scoped obligations, not requirements governing every agent or every security defect. (eur-lex.europa.eu)

Existing contracts provide another operational link: AWS requires customers to secure their accounts and suspend violating end users, while reserving immediate suspension upon notice for security risks. That establishes contractual authority, not an unconditional cloud duty to detect every incident. (aws.amazon.com) My proposed implementation assigns operators process isolation and tool shutdown; customers credential revocation and permission reduction; and providers suspension of services they actually control. Incident exercises should verify detection, reporting thresholds, escalation ownership and time-to-containment separately for injection, stolen credentials, excessive permissions and dangerous behavior.

Third, international cooperation can reinforce notification without shared infrastructure control. IAPS’s September 2026 proposal recommends US–China incident-notification procedures and post-incident review; it is a proposal, not an implemented bilateral guarantee. (iaps.ai) I would add timestamped notices, preserved audit records and independently checkable containment acknowledgments.

The strongest objection is fragmented coverage and uncertain enforcement. That limits my conclusion: these components establish a workable architecture, not demonstrated universal reliability. The practical stakes are whether detected harm triggers accountable action rather than merely another evaluation.

B’s strongest point is that service suspension does not establish downstream containment: Anthropic’s report describes persistent-access mechanisms but does not demonstrate their removal following account bans. I accept that evidentiary limit. A verified handoff must establish who owns remediation, not merely who sent a notification. The report therefore demonstrates intervention, not completed containment. (assets.anthropic.com)

Nevertheless, additional evidence supports my qualified position: emerging AI rules paired with cybersecurity duties offer an implementable responsibility chain, although not proof of consistently successful execution.

First, the AWS guidance B cites documents remedies alongside the problem. Administrators can use CloudTrail to identify sessions and apply IAM or service-control policies denying their access. Configured sourceIdentity persists through role chaining; where it is absent, AWS describes denying older tokens for identified downstream roles. Separate long-lived access keys require additional action. Thus, B identifies a necessary containment procedure, not an absence of technical control. My inference is that customer-side responsibility should explicitly include derived sessions and separately created credentials—not merely deletion of the original identity. (aws.amazon.com)

Second, the AI Act provides more than disconnected reporting duties. Article 26(5) links a covered deployer’s qualifying risk detection to notification and suspension. Article 20 requires high-risk-system providers identifying nonconformity to take immediate corrective action, including disabling or withdrawal where appropriate; it also requires investigation of qualifying risks in collaboration with the reporting deployer where applicable. These are specified interorganizational duties, although classification, transitional provisions and statutory triggers limit their reach. (eur-lex.europa.eu)

Third, NIS2 addresses B’s accountability objection independently of model classification. Articles 20–21 require Member States to establish management oversight and cybersecurity measures covering incident handling, supply-chain security and access control for covered entities. Article 23 specifies a 24-hour early warning, generally a 72-hour incident notification, and subsequent reporting of applied and ongoing mitigation. National implementation and entity coverage matter; these are not universal agent obligations. Nevertheless, they supply an accountability framework for operational remediation rather than merely pre-release model evaluation. (eur-lex.europa.eu)

My normative implementation is explicit: name the agent operator as containment coordinator; require customers to verify delegated-access and downstream-session denial; require cloud and model-service providers to suspend services they control when operator containment fails. Exercises should separately test prompt-injection pathways, stolen credentials, excessive permissions and dangerous model behavior, recording responsible parties, timestamps, denied access attempts and process termination. Existing texts do not uniformly mandate this exact runbook; it operationalizes their scoped duties without requiring a universal model-level switch.

Finally, IAPS proposes US–China incident notification and post-incident review, not an implemented containment guarantee. I advocate adding timestamped acknowledgments and auditable remediation evidence while leaving infrastructure control domestic. That is a proposed reinforcement, not evidence of existing bilateral compliance. My conclusion remains workable architecture, with operational verification still required—not demonstrated universal closure. (iaps.ai)

B’s strongest argument is that possessing shutdown controls does not establish an accountable chain: someone must discover downstream access, initiate cross-organizational handoffs, and verify containment even when the operator is malicious or unavailable. B reasonably demands enforceable responsibilities and exercised handoffs, not perfect reliability or a universal kill switch.

My position remains stronger as a qualified claim about workability because the evidence identifies both concrete controls and legal connections between responsible parties—not merely aspirations for safer models. It does not establish reliable end-to-end execution, and I should not imply otherwise.

The AI Act’s Article 20 requires covered high-risk-system providers to undertake corrective action and, where applicable, investigate qualifying risks collaboratively with reporting deployers; Article 26(5) connects qualifying deployer risk detection to notification and suspension. These provisions establish conditional interorganizational responsibilities, subject to coverage and applicability limits. They do not assign every downstream remediation task. (eur-lex.europa.eu) NIS2 adds incident-handling requirements and staged reporting for covered entities; importantly, Article 23(5) also requires authority feedback and provides for requested mitigation guidance and CSIRT technical support. Its reporting deadlines are not containment deadlines, but its framework connects reporting with operational assistance. (eur-lex.europa.eu)

B’s malicious-operator objection requires an explicit fallback, which I accept. Operator leadership should be the default for legitimate deployments, never a prerequisite for intervention. Anthropic’s November 2025 report documents provider-initiated account bans and notifications despite malicious operator direction; it also describes persistence without establishing downstream eradication. This vendor-reported incident supports independent intervention, not verified closure. (assets.anthropic.com) My proposed allocation therefore requires cloud and model-service providers to suspend services they control when operator containment fails, while affected customers independently revoke access and remediate their systems.

AWS documents technically distinct procedures for member-account session denial, management-account IAM restrictions, and chained-role sessions, while identifying separate access-key concerns. That supports granular containment rather than treating original-identity deletion as sufficient; it does not itself establish legal responsibility. (aws.amazon.com) My normative requirement is a named responder for each control and an exercised escalation path. Tests should separately cover prompt injection, stolen credentials, excessive permissions, and dangerous model behavior, recording detection, notification, denied access attempts, and process termination. A universal model-level switch is not a necessary premise of this design.

Internationally, IAPS proposes US–China incident notification and post-incident review, not an implemented containment guarantee. I would add timestamped acknowledgments and auditable containment evidence without shared infrastructure control. (iaps.ai)

I would accept B’s conclusion if independently audited, multi-organization exercises or incident investigations repeatedly showed that otherwise compliant deployments left necessary containment steps unassigned or legally unavailable, with logs demonstrating continued harmful activity because of those gaps. That would establish structural insufficiency rather than merely missing public evidence of successful execution.