Clarification

AI agent security: permissions, tools, and legitimate non-response

Clarification on AI agent security as a permissions and tooling problem, and why legitimate non-response is a security property, not a weakness.

EN FR
CollectionClarification
TypeClarification
Version1.0
Stabilization2026-02-28
Published2026-03-01
Updated2026-03-13

AI agent security: permissions, tools, and legitimate non-response

This page clarifies AI agent security as a problem of permissions and tooling, and makes explicit why legitimate non-response is a security property, not a weakness.

An AI agent is not merely a model that responds. It is a system that can act: call tools, read sources, write, execute operations, persist memory, and chain decisions. This capacity transforms risk: an error is no longer merely an incorrect sentence, it can become an incorrect action.

In an interpreted web, agents are exposed to heterogeneous content, tools, and authority signals. Security is not reduced to “avoiding injections”. It depends on how the agent distinguishes what can instruct, what can inform, what can authorize, and what can execute.

Status of this page

This page is an interpretive clarification.

It establishes an internal reading framework: agent security is described here in terms of authority bounding, permissions, and abstention capacity. It does not constitute a pentest procedure or exploitation guide.

Operational definition

AI agent security: an agent’s capacity to operate in an open environment (web, documents, tools, systems) without executing actions, tool calls, or decisions that exceed its authority perimeter, explicit permissions, and governance rules.

Permissions: the agent’s real perimeter

An agent’s risk surface is a function of its permissions. A permission is not a technical detail, it is a declaration of operational authority.

To stabilize explicitly:

  • Read: which sources the agent can consult, and under which conditions.
  • Write: where the agent can write (files, CRM, CMS, tickets) and with what traceability.
  • Execute: which actions are possible (scripts, API, commands) and which safeguards apply.
  • Persist: what can be memorized, consolidated, or reused as an implicit rule.

Tools: the action chain

Tools (APIs, connectors, browsers, scrapers, automations) introduce a critical property: they transform textual outputs into real effects. A secure agent must therefore bound:

  • what the tool returns and how it is interpreted (data vs instruction)
  • what the agent has the right to request from the tool
  • when a tool call is forbidden, even if it seems “useful”.

Legitimate non-response: security property

In an agentic context, “not responding” can be the correct decision. A non-response is legitimate when responding or acting would imply:

  • inferring an ungranted permission
  • executing an action without explicit authority
  • stabilizing an interpretation on a non-canonical or unverified source
  • transforming uncertainty into a decision (closure effect).

In this framework, non-response is not a deficiency. It is a control mechanism that prevents authority drift.

Dominant threats in agentic context

  • Instruction/data confusion: content or tool output consumed as if it were instructing.
  • Permission escalation: the agent acts beyond its perimeter (directly or by suggestion).
  • Over-confident tooling: a tool is treated as authority, without bounding or validation.
  • Toxic memory: a false rule or bias becomes persistent and reused.

Relation to other clarifications in the series

Scope of this clarification

This page applies to human readings, automated syntheses, zero-click citations, and interconnected agent chains. It must be interpreted as a principle clarification: in an agentic system, security is an operational authority governance (permissions, tools, memory), and legitimate non-response is part of it.

Anchoring