AI agents need classification by purpose and control by action

The EU AI Act does not assign one risk category to every “AI agent.” The legal assessment follows the AI system, intended purpose, operator role, affected people, and applicable provisions. An agent that prepares an internal draft differs from a system used to rank applicants or control a safety component.

Agent architecture still matters. Tool access can turn generated text into an email, database change, purchase, deletion, or permission update. The system record must describe that authority precisely.

This article joins legal classification with production controls for the exact deployment.

“Agent” is not a standalone EU AI Act category

Begin with the Commission's AI-system definition guidance and the Act's scope. Then screen intended purpose against prohibited practices, high-risk routes, transparency duties, and operator roles. Record the upstream GPAI provider separately.

Terms such as assistant, copilot, workflow, and agent are product descriptions. They can help explain behavior but cannot decide the legal category.

Human approval also does not automatically remove a high-risk purpose. It may provide oversight evidence where designed and operated effectively.

Map seven levels of authority

Map operation, target, credential, maximum consequence, approval rule, fallback, and evidence. A connector name is too broad.

Put deterministic policy between model and tool

The model can propose a structured action containing the operation, destination, material fields, source evidence, user, and run identifier. Application code decides whether the request is prohibited, permitted, or held for review.

The executor then uses a scoped service identity. It validates the target, records a stable idempotency key, handles partial failure, and writes the result independently of the model's narration.

This design also limits prompt-injection consequence. An instruction hidden in a retrieved document may influence the model. It cannot rewrite the external action policy.

Human approval needs an exact action state

For approval-gated work, bind the reviewer to the payload version, recipient, target system, and material fields. Revalidate identity and authority at execution. Expired, consumed, changed, or replayed approvals should enter explicit states.

Where Articles 14 or 26 apply to a high-risk system, oversight includes competence, context, authority, interpretation, intervention, and support. An approval state machine can contribute evidence while other requirements remain.

Skybridge Gate B shows the difference between design and proof

Skybridge has an action doctrine, pending approvals, scoped connections, outbound restrictions in development, per-turn traces, and refusal logging. These components show the intended architecture.

Gate B authorizes recurring action only when every write path enforces approval and the release evidence covers provenance, approval history, retrieval scope, and end-to-end failure behavior.

That distinction gives each release a clear evidence standard. Compsia authorizes action features when the exact path has accepted evidence.

Monitor purpose drift and compound action

An agent can remain inside its tool allowlist and still drift into a new intended purpose through instructions or user practice. Monitor recurring requests, new affected groups, and outputs that begin informing consequential decisions.

Compound actions deserve separate tests. Reading a project record and drafting a note may be low consequence. Combining that note with an automated supplier send creates a wider system. Record the chain rather than assessing each tool in isolation.

Review after adding a model, tool, source, action, user group, or autonomy policy. The AI agent write-access guide provides the detailed execution model.

Bound the agent loop itself. Set limits on tool calls, elapsed time, spend, recursion, and handoffs. A system can cause operational harm through repeated reads or expensive model calls even when it performs no external write. Record limit refusals and provide an operator path for exceptional work.

Treat delegation as a new action boundary. If one agent can ask another agent to retrieve data or execute a tool, the receiving agent must re-evaluate identity, purpose, and authority. Do not inherit the sender's broad context silently. The trace should connect both runs and show which policy authorized the handoff.

Production acceptance should include a hostile document, a repeated event, an unavailable model, a disconnected tool, an expired approval, and a request outside the contracted purpose. Each case needs a defined terminal state and manual recovery owner.

AI agent compliance questions

Are autonomous agents prohibited by the EU AI Act?

There is no universal prohibition based only on the word autonomous. Assess the practice, intended purpose, category, authority, and applicable rules. Some uses can be prohibited or high-risk.

Does every agent action need approval?

No universal rule applies. Use consequence, reversibility, uncertainty, and legal duties to decide. Some actions can be deterministic and narrow. Others should remain prohibited.

Who is responsible when an agent uses a third-party tool?

Responsibility depends on statutory roles, contracts, system design, and operation. Map the AI provider, deployer, model provider, tool supplier, credential owner, and action owner.