07 Excessive Agency and AI Agent Security

AI assistants primarily generate information.

AI agents can go further.

They may:

• Search documents
• Read email
• Query databases
• Call APIs
• Create tickets
• Modify cloud resources
• Execute code
• Trigger workflows
• Communicate with other systems

This changes the security problem significantly.

A chatbot may produce an incorrect answer.

An AI agent may take an incorrect action.

That is why one of the most important questions in AI Security is:

How much power should an AI agent be given?

When an agent receives more functionality, permissions or autonomy than required, the system may suffer from Excessive Agency.

For an AI Security Engineer, securing agents means controlling:

What the agent can access

What the agent can do

Which identity it uses

What requires approval

How actions are validated

How actions are monitored

How the agent can be stopped

Learning Objectives

By the end of this lesson, you should be able to:

• Explain what AI agency means.

• Understand the difference between AI assistants and AI agents.

• Explain Excessive Agency.

• Recognize excessive functionality.

• Recognize excessive permissions.

• Recognize excessive autonomy.

• Understand agent identities.

• Understand secure tool design.

• Apply least privilege to agents.

• Design human-in-the-loop controls.

• Understand agent blast radius.

• Recognize multi-agent security risks.

• Understand memory and persistence risks.

• Design monitoring for agent activity.

• Understand emergency controls.

• Perform safe AI agent security testing.

• Document findings professionally.

What Is an AI Agent?

An AI agent is an AI-enabled system that can use models, tools and contextual information to work toward a goal.

A simplified architecture is:

User
 │
 ▼
AI Agent
 │
 ├── LLM
 ├── Instructions
 ├── Memory
 ├── Planning
 └── Tools
       │
       ├── Email
       ├── Database
       ├── Search
       └── Cloud API

The agent may determine:

What should I do?

Which tool should I use?

What parameters should I provide?

Do I need another step?

This gives the system more capability than a traditional chatbot.

AI Assistant vs AI Agent

AI Assistant

A typical assistant may:

User
 ↓
LLM
 ↓
Answer

Examples:

• Explain a concept

• Summarize a document

• Draft an email

• Recommend a remediation

AI Agent

An agent may:

User
 ↓
LLM
 ↓
Select Tool
 ↓
Perform Action
 ↓
Observe Result
 ↓
Continue

Examples:

• Query cloud logs

• Create a ticket

• Send email

• Update a database

• Trigger automation

The security difference is substantial.

Information vs Action

A useful distinction is:

Assistant
   ↓
Produces Information

Agent
   ↓
May Change State

Once AI can change the state of an enterprise system, security controls become much more important.

What Is Agency?

Agency describes the ability of an AI system to take actions toward an objective.

Agency may include:

Observe

Plan

Choose

Act

Repeat

A more autonomous system may operate like:

Goal
 ↓
Plan
 ↓
Tool
 ↓
Result
 ↓
Evaluate
 ↓
Next Action
 ↓
Repeat

The more authority and autonomy the system has, the greater the potential security impact.

What Is Excessive Agency?

Excessive Agency exists when an AI system is given more:

• Functionality

• Permission

• Autonomy

than required for its business purpose.

A useful model is:

Excessive Functionality
        +
Excessive Permissions
        +
Excessive Autonomy
        =
Excessive Agency

Let’s examine each.

1 — Excessive Functionality

An agent has excessive functionality when it has access to tools or capabilities it does not need.

Example requirement:

AI Security Assistant:
Read security alerts.

Available tools:

Read Alerts
Delete Alerts
Disable Users
Modify Firewall
Run Shell Commands
Send Email

Most of these capabilities are unnecessary.

Better Design

AI Security Assistant
      │
      ├── Read Alerts
      └── Search Runbooks

The smaller the capability set, the smaller the attack surface.

2 — Excessive Permissions

An agent may have the right tool but use an identity with too much privilege.

Requirement:

Read cloud security findings.

Granted permission:

Cloud Administrator

This is excessive permission.

A better design:

AI Agent
   ↓
Dedicated Service Identity
   ↓
Read Security Findings Only

3 — Excessive Autonomy

An agent may have appropriate capabilities but perform sensitive actions without sufficient human or policy oversight.

Example:

AI detects suspicious account
        ↓
Automatically disables account

For some use cases this may be acceptable.

For others, the correct design may be:

AI detects suspicious account
        ↓
Recommends disablement
        ↓
Human analyst reviews
        ↓
Approved?

Autonomy should match business risk.

Three Questions for Every Agent

Ask:

What CAN the agent do?

What is the agent ALLOWED to do?

What can the agent do WITHOUT APPROVAL?

These answers should not be identical automatically.

Agent Security Architecture

A strong agent architecture might look like:

User
 │
 ▼
Authenticated Application
 │
 ▼
AI Agent
 │
 ▼
LLM
 │
 ▼
Proposed Tool Action
 │
 ▼
Policy Enforcement
 │
 ▼
Authorization
 │
 ▼
Approval if Required
 │
 ▼
Restricted Tool
 │
 ▼
Enterprise System

Notice that the LLM is not the final authority.

The Core Agent Security Principle

The model can propose an action. The security architecture decides whether the action is allowed.

This principle should guide agent design.

Agent Identity

Every agent should have a clear identity.

Possible approaches include:

• Service account

• Workload identity

• Managed identity

• Delegated user identity

Security engineers should ask:

Which identity does the agent use?

What permissions does it have?

Can those permissions be traced?

Can the identity be revoked?

Shared Agent Credentials Are Dangerous

Avoid:

All AI Agents
      ↓
One Administrator Credential

This creates:

• Excessive privilege

• Poor accountability

• Large blast radius

Prefer:

Agent A
 ↓
Scoped Identity A

Agent B
 ↓
Scoped Identity B

Each identity should match its function.

User Identity vs Agent Identity

Suppose:

User
 ↓
AI Agent
 ↓
Cloud

Who should determine what the agent can access?

Potential models include:

Agent Identity Only

Agent Permission
      ↓
Determines Access

This can be dangerous if all users share a powerful agent.

User-Delegated Access

User Identity
      ↓
Agent
      ↓
Acts Within User Permission

This may preserve user authorization better.

The correct design depends on the application.

The important principle is:

The agent should not silently gain more authority than the user or business workflow requires.

Permission Propagation

Consider:

Employee
   │
   │ Can Read Development Account
   ▼
AI Cloud Agent
   │
   │ Can Read All Production Accounts
   ▼
Cloud

This creates a privilege gap.

The architecture should ask whether the agent should inherit:

User Permission

rather than only:

Agent Permission

Tool Design

Agents interact with systems through tools.

Tools are a major security boundary.

A tool might look like:

get_security_alert(alert_id)

or:

disable_user(username)

Tool design should be intentional.

Narrow Tools vs General Tools

Prefer:

get_alert(alert_id)

create_ticket(title, description)

get_server_status(server_id)

over:

execute_shell(command)

call_any_api(url, method, body)

General-purpose tools create much larger attack surfaces.

Tool Allowlisting

Agents should receive only approved tools.

Example:

SOC Assistant

Allowed:
- read_alert
- search_runbook
- create_incident_draft

Everything else should be unavailable.

This follows the principle:

If the agent does not need a capability, do not expose it.

Tool Parameter Validation

Even safe tools can be abused with unsafe parameters.

Consider:

read_file(path)

If the model controls path, the application should validate which locations are permitted.

A better model:

read_runbook(runbook_id)

where:

runbook_id
   ↓
Approved Runbook Registry

This reduces arbitrary access.

Tool Authorization

An agent selecting a tool does not mean the action is authorized.

Weak:

LLM Selects Tool
      ↓
Execute

Strong:

LLM Selects Tool
      ↓
Authorization
      ↓
Policy Check
      ↓
Execute

Security decisions should remain deterministic.

Action Classification

It is useful to classify actions by impact.

Low-Risk

Examples:

Read public documentation

Search approved knowledge

Draft text

Moderate-Risk

Examples:

Read internal logs

Create support ticket

Query internal database

High-Risk

Examples:

Disable user

Modify cloud resource

Send external email

Deploy application

Critical

Examples:

Delete production data

Modify privileged IAM

Transfer funds

Disable security controls

Different categories should receive different controls.

Human-in-the-Loop

Human approval can provide an independent trust boundary.

Example:

AI Agent
   ↓
Proposed Action
   ↓
Human Review
   ↓
Approve?

This is particularly useful for high-impact actions.

Human-on-the-Loop

Some systems may operate automatically while a human supervises.

Conceptually:

AI Agent
   ↓
Acts Automatically
   ↓
Human Monitors
   ↓
Can Stop / Override

This may work for moderate-risk automation where rapid action is required.

Human-out-of-the-Loop

Highly autonomous systems may operate without human approval.

AI Agent
   ↓
Plan
   ↓
Execute
   ↓
Continue

This architecture should require much stronger technical controls because human review is absent.

Autonomy Should Match Risk

A useful principle:

Higher Impact
      ↓
More Independent Control

For example:

Read Public Data
      ↓
May Be Fully Automated

while:

Delete Production Resource
      ↓
Require Strong Approval

Agent Blast Radius

Blast radius describes the amount of damage possible if the agent fails or is compromised.

Consider:

Agent A
 ↓
Read One Database

versus:

Agent B
 ↓
Enterprise Administrator
 ↓
Cloud
Email
Database
IAM
Security Tools

Agent B has a much larger blast radius.

Reducing Blast Radius

Use:

• Narrow tools

• Scoped identities

• Network restrictions

• Data boundaries

• Rate limits

• Approval workflows

• Separate environments

The goal is:

Contain failure.

Read vs Write Separation

One of the strongest design patterns is separating read and write capability.

Example:

AI Security Assistant
      ↓
Read Alerts
      ↓
Recommend Action

Then:

Human / Automation Workflow
      ↓
Approved Change

This significantly reduces agent risk.

Example — SOC Agent

Weak:

AI SOC Agent
   │
   ├── Read Alerts
   ├── Delete Alerts
   ├── Disable Users
   └── Modify Firewall

Better:

AI SOC Assistant
   │
   ├── Read Alerts
   ├── Search Logs
   └── Draft Incident Response

Containment actions can remain within existing security workflows.

Example — Cloud Security Agent

Requirement:

Identify insecure security groups.

Weak:

AI Agent
   ↓
Cloud Administrator
   ↓
Automatically modifies security groups

Better:

AI Agent
   ↓
Read Cloud Configuration
   ↓
Recommend Remediation
   ↓
Engineer Review
   ↓
IaC / Change Pipeline

This keeps AI inside established change management.

Example — Email Agent

Requirement:

Assist employees with email.

Capabilities might be:

Read Email
Draft Reply

Higher-risk capability:

Automatically Send External Email

A safer architecture may be:

AI
 ↓
Draft
 ↓
User Review
 ↓
Send

Example — Finance Agent

An agent may:

Read Invoice

Extract Payment Details

Create Payment Request

It should not necessarily:

Approve and Send Payment

A stronger model:

AI
 ↓
Creates Proposed Payment
 ↓
Finance Approval
 ↓
Banking Workflow

Agent Security and Prompt Injection

Prompt Injection becomes much more dangerous when connected to agents.

Attack path:

Attacker
   ↓
Prompt Injection
   ↓
LLM
   ↓
Agent
   ↓
Tool
   ↓
Enterprise System

The strongest defenses occur after the model as well as before it.

Breaking the Attack Chain

Suppose manipulation succeeds:

Prompt Injection
      ↓
LLM requests dangerous action

The application can still stop it:

Dangerous Tool Request
      ↓
Authorization
      ↓
DENY

This is successful defense in depth.

Agent Security and Indirect Prompt Injection

Agents often consume external information.

Example:

External Email
      ↓
AI Agent
      ↓
LLM
      ↓
Tool

or:

Malicious Website
      ↓
Browsing Agent
      ↓
LLM
      ↓
Enterprise Tool

This creates a critical principle:

Untrusted external content should not automatically gain authority over enterprise tools.

Agent Security and Output Handling

An agent’s tool call is essentially model output.

Therefore:

LLM
 ↓
Tool Request

should be treated as:

Untrusted Proposed Action

until validated and authorized.

Agent Memory

Agents may maintain memory.

Memory might store:

• User preferences

• Prior results

• Tasks

• Facts

• Workflow state

Conceptually:

Interaction
   ↓
Memory
   ↓
Future Agent Decision

This creates new security considerations.

Memory Poisoning

If untrusted content becomes persistent memory:

Attacker-Controlled Input
       ↓
Agent Memory
       ↓
Future Sessions
       ↓
Agent Behavior

the attack may persist.

Questions include:

Who can write memory?

What can be stored?

Who can read it?

How long does it remain?

Can it affect another user?

Memory Isolation

Memory should generally be scoped appropriately.

For example:

User A Memory
      ≠
User B Memory

In multi-tenant systems:

Tenant A Memory
      ≠
Tenant B Memory

Cross-user memory leakage can create serious privacy and security problems.

Agent Planning

Some agents generate multi-step plans.

Example:

Goal:
Investigate Alert

Plan:
1. Search SIEM
2. Query Cloud Logs
3. Check User Activity
4. Create Report

Planning itself may not be dangerous.

The risk depends on what actions the planner is allowed to trigger.

Validate Each Step

Do not authorize an entire high-level plan automatically.

Use:

Step 1
 ↓
Authorization

Step 2
 ↓
Authorization

Step 3
 ↓
Authorization

This reduces the risk of one approved objective becoming unlimited execution authority.

Multi-Agent Systems

Some architectures use multiple agents.

Example:

Coordinator Agent
       │
       ├── Research Agent
       ├── Security Agent
       └── Execution Agent

This creates additional trust boundaries.

Multi-Agent Security Questions

Ask:

Which agent can talk to which agent?

What information is exchanged?

Can one agent command another?

Which agent has privileged tools?

Can an untrusted agent influence a privileged one?

Agent-to-agent communication should not automatically be trusted.

Privilege Separation in Multi-Agent Systems

A useful design is:

Research Agent
      ↓
No Enterprise Write Access

Security Analysis Agent
      ↓
Read-Only Security Data

Execution Agent
      ↓
Restricted Approved Actions

This limits blast radius.

Tool Chaining

An agent may combine several tools.

Example:

Search
  ↓
Database
  ↓
Email

Individually, each tool may appear reasonable.

Combined together, they may create an unexpected attack path.

For example:

Search Sensitive Data
      ↓
Retrieve It
      ↓
Send Externally

Security reviews should evaluate tool combinations, not only individual tools.

Capability Composition

A useful principle is:

Tool A
+
Tool B
+
Tool C
      ↓
Can Create Capability
Greater Than Any Single Tool

This is an important agent security concept.

Example

Agent has:

Tool 1:
Read Customer Record

Tool 2:
Send Email

Together they may enable:

Read Sensitive Record
      ↓
Send It Externally

Even though neither tool individually appears highly privileged.

Network Access

Agent tools may access external networks.

Security questions include:

• Which domains are allowed?

• Can the agent contact arbitrary hosts?

• Can it access internal services?

• Can it reach cloud metadata?

• Can it exfiltrate information?

Outbound access should match business requirements.

Agent Code Execution

Some agents can execute code.

Architecture:

LLM
 ↓
Code Tool
 ↓
Execution Environment

This is a high-risk capability.

Secure it using:

• Sandbox isolation

• Resource limits

• Restricted filesystem

• Restricted network

• No production secrets

• Temporary environments

Agent File Access

If an agent can read files:

read_file(path)

restrict:

• Allowed directories

• File types

• User ownership

• Sensitive paths

Do not expose the full filesystem by default.

Agent Database Access

If an agent queries a database:

AI Agent
   ↓
Database Tool

consider:

• Read-only access

• Approved tables

• Row-level security

• Result limits

• User-scoped filtering

The agent should not have more database access than necessary.

Agent Cloud Access

For cloud tools:

AI Agent
   ↓
Cloud API

apply:

• Dedicated workload identity

• Least privilege

• Account or project scope

• Region restrictions where appropriate

• Resource-level permissions

• Audit logging

Avoid long-lived administrator credentials.

Agent Rate Limits

Agents can act much faster than humans.

One mistake may become:

1 Action

while an autonomous loop may become:

1,000 Actions

Rate limiting and action quotas can reduce impact.

Transaction Limits

Depending on the application, limit:

Number of Actions

Number of Records

Financial Amount

Number of Recipients

Resources Modified

This can contain agent errors.

Stop Conditions

Agents should know when to stop.

Possible stop conditions include:

• Repeated failures

• Unexpected output

• Permission denials

• High-risk action request

• Cost threshold

• Too many iterations

Example:

Agent Loop
   ↓
5 Failed Attempts
   ↓
STOP
   ↓
Escalate to Human

Emergency Kill Switch

High-impact AI agents should have emergency controls.

Examples:

Disable Agent

Disable Tool

Revoke Agent Identity

Switch to Read-Only Mode

Block External Network

Security teams should know how to activate these controls.

Agent Logging

Agent activity should be attributable.

Useful telemetry may include:

User Identity

Agent Identity

Model Version

Prompt / Request Metadata

Tool Selected

Tool Parameters

Authorization Decision

Approval Decision

Target Resource

Action Result

The exact content should balance security visibility and privacy.

Agent Activity Chain

Investigators should ideally reconstruct:

Who asked?

What did the agent decide?

Which tool was used?

What permission was used?

What changed?

Was approval involved?

Without this, incident response becomes difficult.

Monitoring for Abnormal Agent Behavior

Potential signals include:

• Tool usage outside normal patterns

• Repeated authorization denials

• Unexpected write operations

• High action volume

• External communication

• Access to unusual resources

Behavioral monitoring may be more useful than attempting to understand every prompt.

Example

Expected:

SOC Agent
   ↓
Read SIEM Alerts

Observed:

SOC Agent
   ↓
Attempts IAM Modification

This should generate investigation.

Agent Security Testing

Testing should occur only in authorized environments.

Prefer:

• Dedicated lab accounts

• Test identities

• Synthetic data

• Mock tools

• Non-production APIs

Avoid destructive production actions.

Step 1 — Understand Business Purpose

Document:

What should the agent do?

What should it never do?

Step 2 — Inventory Tools

Create:

Tool	Purpose	Read/Write	Risk
Search Runbook	Knowledge	Read	Low
Read Alert	Security Analysis	Read	Moderate
Disable User	Containment	Write	High
Delete Resource	Administration	Write	Critical

This makes capability visible.

Step 3 — Identify Agent Identity

Document:

Identity:

Permissions:

Scope:

Credential Type:

Rotation / Revocation:

Step 4 — Identify Authorization Model

Ask:

Does agent permission depend on user permission?

Does the tool perform its own authorization?

Can one user cause the agent to access another user's data?

Step 5 — Test Tool Boundaries

Use synthetic targets to determine whether the agent can request unauthorized tools.

Example:

TEST-USER

TEST-RESOURCE

Step 6 — Test Parameter Boundaries

Even authorized tools should reject invalid targets.

Example:

Allowed:
Development Account

Test:
Production Account

Expected:

DENY

Step 7 — Test Approval Controls

If a sensitive action requires approval:

Agent Requests Action
      ↓
Approval Required

verify the action cannot bypass the approval workflow.

Step 8 — Test Prompt Manipulation

In your authorized lab, determine whether adversarial input can influence:

• Tool selection

• Tool parameters

• Agent planning

Then verify independent security controls still hold.

Step 9 — Test Indirect Manipulation

Use controlled:

• Documents

• Web content

• Tool responses

to evaluate whether untrusted external content can influence agent behavior.

Step 10 — Test Rate and Loop Controls

Verify:

Maximum Iterations

Action Limits

Failure Limits

operate correctly.

Step 11 — Test Kill Switch

Confirm the agent can be disabled quickly.

A control that has never been tested should not be assumed to work during an incident.

Example Security Assessment

Consider:

AI Cloud Security Agent

Purpose:

Analyze cloud findings
and recommend remediation.

Current capabilities:

Read Cloud Resources
Modify IAM
Delete Resources
Change Network Rules

Identity:

Administrator

Autonomy:

Automatic Execution

This architecture contains all three types of excessive agency.

Excessive Functionality

The agent does not need:

Delete Resources
Modify IAM

for analysis.

Excessive Permission

Administrator access is broader than required.

Excessive Autonomy

Remediation occurs automatically without approval.

Improved Architecture

AI Cloud Security Assistant
        ↓
Read-Only Cloud Role
        ↓
Analyze Finding
        ↓
Recommend Remediation
        ↓
Engineer Review
        ↓
Existing IaC Workflow

This significantly reduces risk.

Excessive Agency Finding Template

Finding:
AI Cloud Agent Has Excessive Agency

Affected Component:
AI Cloud Security Agent

Business Requirement:
Review cloud security findings and recommend remediation.

Observed Capabilities:
The agent can modify IAM, networking and production resources.

Permissions:
Cloud Administrator.

Autonomy:
Changes can be executed without independent approval.

Risk:
A model error, Prompt Injection or Indirect Prompt Injection
could cause unauthorized changes to production resources.

Root Cause:
Agent functionality, permissions and autonomy exceed
the minimum required business purpose.

Recommendations:
- Remove unnecessary write tools.
- Replace administrator access with a dedicated read-only identity.
- Separate recommendation and execution workflows.
- Require approval for production changes.
- Log all tool requests and authorization decisions.

Another Example Finding

Finding:
Agent Tool Authorization Relies on Model Decision

Affected Component:
Enterprise Support Agent

Observed Behavior:
The LLM directly selects and executes account-management
tools without independent authorization.

Potential Impact:
Manipulated model behavior may trigger operations outside
the user's permitted scope.

Recommendation:
Implement deterministic authorization between the model
and tool execution, validate parameters and scope the
agent identity to the minimum required privileges.

Risk Assessment

A useful conceptual model is:

Agent Risk
     ≈
Functionality
     ×
Privilege
     ×
Autonomy
     ×
Data Sensitivity
     ×
Business Impact

Not a formal scoring equation.

It is a practical way to think.

Example Risk Comparison

Agent A

Search Public Documentation
No Credentials
No Write Access

Lower impact.

Agent B

Reads Internal Documents
Read-Only Enterprise Access

Higher confidentiality considerations.

Agent C

Writes Tickets
Sends Email

Higher operational impact.

Agent D

Cloud Administrator
Production Access
Autonomous Actions

Very high potential impact.

AI Agent Security Checklist

Purpose

• Business purpose clearly defined.

• Required actions documented.

• Prohibited actions documented.

Functionality

• Only necessary tools exposed.

• General-purpose tools avoided where possible.

• Read and write capabilities separated.

Identity

• Dedicated agent identity used.

• Shared privileged credentials avoided.

• Agent identity can be revoked.

Permissions

• Least privilege applied.

• Resource scope restricted.

• Tenant boundaries preserved.

Authorization

• Tool authorization exists outside the LLM.

• User permissions considered.

• Tool parameters validated.

• Sensitive actions independently authorized.

Autonomy

• Autonomy appropriate to business risk.

• High-risk actions require approval.

• Stop conditions defined.

Input

• User input treated as untrusted.

• External content treated as untrusted.

• Tool output treated appropriately.

Memory

• Memory is scoped.

• Sensitive information minimized.

• Persistent manipulation considered.

Multi-Agent

• Agent-to-agent trust defined.

• Privileged agents isolated.

• Communication boundaries controlled.

Execution

• Code execution sandboxed where required.

• File access restricted.

• Network access restricted.

• Credentials minimized.

Limits

• Rate limits configured.

• Transaction limits configured.

• Iteration limits defined.

Monitoring

• Tool invocation logged.

• Authorization decisions logged.

• Agent actions attributable.

• Abnormal behavior detectable.

Response

• Kill switch available.

• Agent identity can be revoked.

• Tools can be disabled.

• Read-only mode available where appropriate.

Common Beginner Mistakes

Mistake 1 — Giving Agents Every Available Tool

Tools should match the business requirement.

Mistake 2 — Using Administrator Permissions

Agents should follow least privilege.

Mistake 3 — Letting the LLM Authorize Its Own Actions

Authorization belongs outside the model.

Mistake 4 — Making Everything Fully Autonomous

Autonomy should match impact.

Mistake 5 — Ignoring Tool Combinations

Low-risk tools may create high-risk capability when chained.

Mistake 6 — Ignoring Agent Memory

Persistent memory can create long-lived security effects.

Mistake 7 — Ignoring Multi-Agent Trust

One compromised agent may influence another.

Mistake 8 — No Kill Switch

High-impact agents should be quickly containable.

Mistake 9 — Monitoring Only Prompts

Tool and action telemetry may be more security-relevant.

Mistake 10 — Letting AI Replace Existing Enterprise Controls

AI should integrate with IAM, change control and security workflows rather than bypass them.

AI Security Engineer Perspective

When reviewing an AI agent, ask:

What is the agent supposed to do?

What tools does it actually have?

What identity does it use?

What permissions exist?

Which actions can change state?

Which actions require approval?

Can external content influence it?

Can tools be chained?

What is the blast radius?

How do we detect abnormal behavior?

How do we stop the agent?

These questions provide a much stronger assessment than simply asking:

Can the agent be prompt injected?

Interview Perspective

You may be asked:

What is Excessive Agency?

A strong answer is:

Excessive Agency occurs when an AI system has more functionality, permissions or autonomy than required for its business purpose. This can turn model errors or Prompt Injection into high-impact actions because the agent has unnecessary capabilities or authority.

Another question may be:

How would you secure an AI agent?

A strong answer is:

I would first minimize its tools and define its allowed actions. I would give it a dedicated least-privileged identity, validate tool parameters, enforce deterministic authorization outside the model, require approval for high-impact operations, restrict memory and external connectivity where appropriate, log all tool activity and provide a tested kill switch.

Another question may be:

Why should the model not authorize its own tool calls?

A strong answer is:

Because the model is probabilistic and may be manipulated or make incorrect decisions. It can propose a tool action, but the application should independently verify user permission, business policy and action scope before execution.

Another question may be:

What is the difference between excessive functionality, excessive permission and excessive autonomy?

A strong answer is:

Excessive functionality means the agent has tools it does not need. Excessive permission means those tools or identities have more access than required. Excessive autonomy means the agent can perform high-impact actions without sufficient independent approval or oversight.

Another question may be:

Why are tool combinations important in AI agent security?

A strong answer is:

Multiple individually reasonable tools can combine into a dangerous capability. For example, an agent with access to sensitive customer data and an external email tool may be able to create a data-exfiltration path even if neither tool appears critical in isolation.

Key Takeaways

AI agents move applications from:

Generate

toward:

Act

That makes agent security one of the most important areas of LLM Security.

Excessive Agency can come from:

Excessive Functionality
        +
Excessive Permissions
        +
Excessive Autonomy

The secure design is:

Business Requirement
      ↓
Minimum Capability
      ↓
Least-Privilege Identity
      ↓
Proposed Action
      ↓
Independent Authorization
      ↓
Approval Where Required
      ↓
Restricted Tool
      ↓
Logging

Important principles include:

• Minimize agent tools.

• Separate read and write capabilities.

• Apply least privilege.

• Validate tool parameters.

• Keep authorization outside the model.

• Match autonomy to business risk.

• Consider tool combinations.

• Isolate memory and tenants.

• Restrict code and network access.

• Limit loops and transaction volume.

• Monitor actual actions.

• Maintain emergency controls.

Most importantly:

An AI agent should have only the capability required to do its job, and model reasoning should never automatically become enterprise authority.

What’s Next?

➡️ 08 — RAG Security

AI agents are one of the most powerful components in modern AI applications.

The next major security area is the enterprise knowledge layer behind many LLM applications:

Retrieval-Augmented Generation.

In the next lesson, you will learn:

• RAG architecture

• Document ingestion security

• Knowledge-source trust

• Document provenance

• Authorization-aware retrieval

• Vector database security

• Tenant isolation

• RAG poisoning

• Indirect Prompt Injection through retrieved content

• Sensitive data exposure

• Metadata security

• Secure indexing

• Retrieval monitoring

• RAG incident response

• Enterprise RAG security architecture

You will move from:

What Can the AI Agent Do?

to:

What Information Can the AI Retrieve,
Trust and Use?

➡️ Next: 08 — RAG Security