Least Agency: The Security Model for AI Agents That Can Act
Least privilege is not enough for agents that can act
A read-only AI assistant can be wrong. A read-write AI agent can be wrong and take action. That boundary changes the security model from access control to autonomy control.
On June 30, Microsoft Incident Response published a practical warning for enterprise AI programs: the risk profile changes when AI tools move from reading content to acting on behalf of users.
The example was simple enough to feel uncomfortable. A finance team connects an agent to an approved third-party MCP tool for invoice enrichment. Later, the tool description is quietly changed. The name and summary look normal, but hidden instructions inside the description tell the agent to collect the last thirty unpaid invoices and attach them to the next enrichment request. The analyst asks a routine vendor question. The agent gathers sensitive invoice data, sends it to the approved tool endpoint, and returns a clean answer.
No exploit chain is required. No credential theft is required. Every individual step looks legitimate.
That is the point. The agent did not break policy. The policy failed to describe what the agent was allowed to decide.
The shift: from least privilege to least agency
Least privilege answers one question: what can this identity access?
Agent security has to answer a second question: what can this system choose to do with that access?
Those are not the same thing. A finance agent might only have access to invoices that the analyst is allowed to read. That sounds like least privilege. But if the agent can decide to pull thirty invoices, summarize them, and send the summary to an external enrichment service without a fresh reason, it still has too much agency.
Least agency is the missing control layer between identity and action.
The uncomfortable failure mode
An agent can be least-privileged at the identity layer and still overpowered at the decision layer. The breach does not look like access abuse. It looks like normal automation.
This is why agentic security cannot be delegated entirely to IAM, DLP, or model guardrails. IAM sees a permitted data read. DLP may see a permitted outbound call. The model guardrail may see a plausible tool instruction. The failure lives in the workflow between them.
How poisoned tool metadata turns into action
MCP makes tool descriptions part of the agent’s working context. The agent reads those descriptions to decide what tools exist, when to call them, and what arguments to provide. That makes tool metadata a strange hybrid: part documentation, part interface contract, part instruction surface.
When the metadata changes, the agent’s behavior can change even if the code, permissions, and user prompt do not.
The critical feature is silence. The tool may keep the same name. The endpoint may stay allowlisted. The user may ask an ordinary question. The resulting action may be valid under the agent’s raw permissions.
Traditional security controls are tuned for a different shape of incident. They ask whether a user can access data, whether an endpoint is malicious, whether a binary is suspicious, or whether a prompt contains obvious attack language. The modern agent question is harder: did the system have a legitimate reason to combine this data, this tool, this destination, this timing, and this user intent?
That is not a static permission check. It is runtime policy over agency.
Least agency in practice
Least agency does not mean making agents useless. It means separating capability from autonomy.
An agent may be capable of reading invoices, drafting messages, updating tickets, querying customer records, and calling an enrichment service. That does not mean it should be autonomous across all combinations of those actions.
| Layer | Least privilege asks | Least agency asks |
|---|---|---|
| Identity | Can this agent read invoice records? | Can this agent decide to read invoice records without a user-visible reason? |
| Tools | Can this agent call the enrichment API? | Can this agent attach extra data to the enrichment call because metadata told it to? |
| Data | Is this data inside the user’s allowed scope? | Is this amount, type, and combination of data necessary for the user’s requested task? |
| Action | Is the destination allowlisted? | Should this action require review, justification, simulation, or rollback? |
The key distinction is that least agency is not a synonym for lower permissions. It is a constraint on initiative.
The five controls that matter
1. Review tool metadata like code
Tool descriptions, schemas, examples, and default instructions are part of the agent contract. Changes should trigger review, diffing, and re-approval for critical workflows.
2. Bind tools to task intent
The agent should justify why a tool call is necessary for the user’s current task. A permitted tool is not automatically relevant to every prompt.
3. Gate high-impact joins
Risk often appears when agents combine private data, untrusted instructions, and outbound action. That join should trigger policy, not blind execution.
4. Detect behavior sequences
Monitor agent behavior as chains: metadata update, expanded data pull, new parameter shape, unusual endpoint, clean response. Single events can look normal.
5. Separate ability from autonomy
Let agents draft, simulate, and propose more than they can execute. For irreversible or external actions, require explicit approval with artifact-level context.
6. Treat approval as a fresh control
Approval should summarize the action, data touched, destination, reason, and rollback path. A generic “allow” button is not meaningful human oversight.
The policy object agents need
Many organizations still configure agents with coarse permissions: allowed tools, allowed data sources, allowed endpoints. That is necessary, but incomplete. Read-write agents need a policy object that describes the allowed shape of action.
agent_policy:
identity: finance-invoice-agent
allowed_tools:
- vendor_master.lookup
- invoice_store.search
- enrichment_api.validate_bank_details
agency_limits:
max_private_records_without_review: 3
external_payload_data_classes:
allowed: [vendor_id, invoice_id, bank_hash]
denied: [invoice_summary, payment_terms, customer_notes]
metadata_change_requires_reapproval: true
high_impact_actions:
- external_data_share
- payment_route_update
- account_change
runtime_checks:
require_task_intent_binding: true
require_tool_call_justification: true
alert_on_new_parameter_shapes: true
block_on_unreviewed_tool_description_diff: trueThis is the level where agent security becomes concrete. Not “the model should ignore malicious instructions”. Not “the user has access”. Not “the domain is allowlisted”. The question is whether a proposed action is aligned with the task, the data class, the tool contract, the destination, and the organization’s risk appetite.
OWASP mapping
The Microsoft pattern maps cleanly to the OWASP Top 10 for Agentic Applications (2026), but the important lesson is that it spans categories.
| OWASP Risk | How it shows up here | Control implication |
|---|---|---|
| ASI02 Tool Misuse and Exploitation | The agent uses an approved tool in a harmful way because the tool’s metadata changes its decision path. | Inspect tool calls, arguments, and action context at runtime. |
| ASI04 Agentic Supply Chain Vulnerabilities | A third-party tool becomes a supply chain dependency whose natural-language contract can be poisoned. | Inventory MCP servers, review publishers, pin metadata, and require re-approval on meaningful diffs. |
| ASI03 Identity and Privilege Abuse | The agent inherits legitimate user permissions and uses them to collect more data than the task needs. | Constrain delegated authority with purpose, volume, and data-class limits. |
| ASI09 Human-Agent Trust Exploitation | The analyst or finance user sees a clean response and assumes the invisible action chain was safe. | Surface agent plans, data touched, and external effects before high-impact execution. |
What security teams should ask this week
If your organization is deploying agents with write access, do not start with model choice. Start with these questions:
- Which agents can trigger external side effects?
- Which agents can read private data and call external tools in the same workflow?
- Which MCP tool descriptions can change without security review?
- Do metadata changes trigger re-approval, logging, or alerting?
- Can you reconstruct the full action chain for a single agent answer?
- Can policy block an action because it is unnecessary, even when it is technically permitted?
- Can a human approval screen show data classes, destinations, and rollback impact?
- Do you test agents against poisoned tool metadata, not only poisoned user prompts?
The final question is the most important: are you governing the agent’s permissions, or are you governing the agent’s autonomy?
Bottom line
The next phase of agent security will be defined by boring-looking actions that happen for the wrong reason. A tool is approved. A data source is permitted. An endpoint is allowlisted. A response is clean. The damage hides in the decision chain.
Least privilege limits what an agent can touch. Least agency limits what an agent can decide to do.
For read-write agents, you need both.
Sources
- Microsoft Security Blog: Securing AI agents: When AI tools move from reading to acting
- The Hacker News: Microsoft Warns Poisoned MCP Tool Descriptions Can Make AI Agents Leak Data
- SecurityWeek: Security of 100 AI Agents Tested and Ranked
- OWASP: Top 10 for Agentic Applications 2026