Excessive Agency — Attack Vectors & Controls (Least Privilege, Permission Inventory, Access Reviews)

When the AI system is granted more autonomy, permissions, or capabilities than its intended purpose requires, unnecessary risk surfaces are created. Excessive agency is not an attack in the traditional sense; it is a design flaw that amplifies the impact of any other vulnerability. A prompt injection attack against a system with minimal permissions causes limited damage; the same attack against an over-permissioned system can be catastrophic.

The principle of least privilege, applied to the AI system’s access rights, API permissions, and action capabilities, is the primary control. The system’s authorised scope is documented in the AISDP (Module 1 defines the intended scope of autonomy) and enforced through technical controls, not merely policy. Every access right, API credential, and action capability should be documented in a permission inventory with a justification for each.

Regular access reviews (quarterly at minimum) confirm that the system’s permissions remain proportionate to its documented purpose. Permissions added during development or testing that are not needed in production should be removed. Any gap between the system’s technical capabilities and its documented intended purpose is an excessive agency risk that the AISDP must acknowledge and control. Module 9 documents the permission inventory and the access review schedule.

Key outputs

• Permission inventory with per-permission justification
• Least-privilege enforcement through technical controls
• Quarterly access reviews confirming proportionate permissions
• Module 1 and Module 9 AISDP documentation

Overreliance — Controls (Human Oversight Enforcement, Automation Bias Countermeasures)

Overreliance occurs when users or downstream systems treat AI outputs as authoritative without adequate verification, leading to propagating errors, hallucinations, or biased outputs. For high-risk systems, this threat undermines Article 14’s human oversight requirement, because oversight that defers uncritically to the model provides no actual safeguard.

This threat is addressed primarily through the human oversight measures: mandatory review workflows, automation bias countermeasures (data-first display, minimum dwell time, confidence visualisation, calibration cases), and override capability with rationale capture. The cybersecurity dimension is the technical enforcement of human review: the system should not be configurable to operate without human oversight for high-risk decisions.

Module 9 should document the technical controls that prevent bypass of human oversight, including how the system enforces mandatory review workflows and prevents operators from bulk-approving recommendations without individual assessment. Module 7 should cross-reference Module 9 for the enforcement mechanisms. Penetration testing should specifically test for human oversight bypass paths.

Key outputs

• Technical enforcement preventing bypass of human oversight
• Cross-reference between Module 7 (human oversight) and Module 9 (enforcement)
• Penetration testing scope including oversight bypass testing
• Module 7 and Module 9 AISDP evidence