Secure Your AI Agents on AWS (Part 1): Inputs, Identity, and Human Oversight

Part 1 of a three-part series mapping the OWASP Top 10 for Agentic Applications 2026 to AWS security controls. This part covers the agent's boundary with users and inputs: goal hijack (ASI01), identity and privilege abuse (ASI03), and human-agent trust abuse (ASI09).

WAZ

Published Jul 23, 2026

Last modified Jul 23, 2026

This is Part 1 of a three-part series mapping the OWASP Top 10 for Agentic Applications 2026 to AWS security controls. Part 1 establishes the framework and covers the agent's "front door" — what it hears, who it is, and when a human signs off. Part 2 covers tool execution and runtime safety. Part 3 covers state, inter-agent communication, and detection.

This is a personal post. The views are my own and do not represent AWS. The code samples are illustrative — validate every API shape against the current documentation and Regional availability before you deploy.

Agentic AI systems make autonomous decisions, select tools dynamically, and maintain persistent memory - capabilities that create security risks traditional controls weren't designed to handle. Whether you're considering or already running these systems, a single compromised agent could expose customer data, approve fraudulent transactions, or create compliance violations.

In this series, I show you how to implement production-ready security controls that protect your AI agents while maintaining their functionality, using AWS services that you can deploy in days rather than months. The Open Worldwide Application Security Project (OWASP) Top 10 for Agentic Applications 2026 provides the industry's first structured framework for agentic AI risks, and I walk you through how to address each one using AWS security and AI services.

Across the three parts, I walk you through:

Why agentic AI needs specialized security - how agents differ from other applications and what that means for your security posture
The OWASP Top 10 framework - a quick overview of each risk category
Defense-in-depth architecture - how AWS services map to security layers across the agentic AI stack
Mitigation strategies with code examples - step-by-step guidance for addressing each OWASP risk using AWS services
Priority implementation roadmap - where to start based on your risk profile

This part covers three risks that govern the agent's boundary with the outside world: ASI01 (agent goal hijack), ASI03 (identity and privilege abuse), and ASI09 (human-agent trust abuse).

Prerequisites

To follow along with the examples in this series, you need:

An AWS account with appropriate permissions to create and manage the services described, and billing alerts configured to avoid unexpected charges
AWS Command Line Interface (AWS CLI) version 2.x or later, installed and configured
Python 3.9 or later with the boto3 library (version 1.26.0 or later)
Familiarity with AWS Identity and Access Management (IAM) roles and policies
Basic understanding of AI and machine learning (ML) concepts, including large language models (LLMs)
AWS Lambda and Amazon CloudWatch experience is helpful

Skill level: Intermediate to Advanced | Time to complete: 1–2 hours for this part | Estimated cost: $5–20 USD for testing

Experience with Amazon Bedrock is helpful but not required - I explain each AgentCore service as I introduce it.

Why agentic AI requires specialized security

Agentic AI systems operate differently from other applications in ways that directly affect your security posture. Where most applications follow deterministic code paths with structured inputs and well-defined trust boundaries, your agentic systems make autonomous decisions, select tools dynamically, and maintain persistent memory across interactions. These characteristics create security risks that need specialized controls.

The following table shows the key differences that create new security risks:

Characteristic	Non-agentic applications	Agentic AI systems
Decision-making	Deterministic code paths	Autonomous multi-step reasoning
Tool usage	Predefined function calls	Dynamic tool selection and chaining
State management	Session-based, ephemeral	Persistent memory across interactions
Trust boundaries	Static, well-defined	Dynamic, context-dependent
Input validation	Structured data formats	Natural language with semantic risks

These differences mean that you need to add AI-specific controls to your defense-in-depth approach - starting with the OWASP framework and the layered architecture I describe next.

Understanding the OWASP Top 10 for agentic applications 2026

Use the OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10) to evaluate risks relevant to your agents. This community-driven taxonomy identifies the top security issues observed across agentic AI deployments. Each entry represents a specific risk category to consider when designing and operating your systems.

This table provides an overview of each issue, and shows which part of this series covers it:

ID	Issue	Description	Covered in
ASI01	Agent goal hijack	Manipulation of agent objectives through prompt injection or poisoned data	Part 1
ASI02	Tool misuse and abuse	Agents misusing legitimate tools due to prompt injection or unsafe delegation	Part 2
ASI03	Identity and privilege abuse	Abuse of dynamic trust and delegation to escalate access	Part 1
ASI04	Supply chain issues	Unintended or unexpected third-party tools, plugins, and agents	Part 2
ASI05	Unexpected code execution	Agents generating and executing unintended code	Part 2
ASI06	Memory and context poisoning	Corruption of agent memory and retrievable context	Part 3
ASI07	Insecure inter-agent communication	Weak authentication in multi-agent message exchanges	Part 3
ASI08	Cascading failures	Single faults propagating across autonomous agents	Part 3
ASI09	Human-agent trust abuse	Abusing human trust to manipulate decisions	Part 1
ASI10	Rogue agents	Unintended or tampered-with agents deviating from intended function	Part 3

Now that you understand the risk landscape, let's look at how to structure your defenses.

Defense-in-depth architecture for agentic AI

No single service or control addresses every agentic AI security risk. As with production workloads, securing agentic AI requires a defense-in-depth approach - layered security controls where each layer addresses distinct threat categories and compensates for gaps in others.

This table maps each security layer to the OWASP Agentic AI issues it mitigates and the primary AWS services involved. Use this mapping as the organizing framework for the mitigation strategies across all three parts of this series.

Security layer	What it protects	OWASP issues addressed	Primary AWS services
Policies and governance	Operational boundaries, compliance requirements, and acceptable use definitions for agent behavior	Foundation for ASI01–ASI10	AWS Well-Architected Framework , AWS Audit Manager
Identity and access management	Authentication, authorization, credential lifecycle, and delegation chains	ASI03 (identity abuse), ASI10 (rogue agents)	Amazon Bedrock AgentCore Identity, AWS Identity and Access Management (IAM), AWS Security Token Service (STS) , Amazon Cognito
Network and edge protection	Agent endpoints, API rate limiting, DDoS protection, and traffic inspection	ASI07 (inter-agent comms), ASI08 (cascading failures)	AWS WAF, AWS Shield, Amazon API Gateway, AWS PrivateLink
Infrastructure protection	Compute isolation, sandbox enforcement, and resource boundaries	ASI05 (code execution), ASI04 (supply chain)	AWS Lambda (Firecracker), Amazon Inspector, Amazon VPC security groups
Application protection	Input/output validation, prompt safety, tool mediation, and goal integrity	ASI01 (goal hijack), ASI02 (tool misuse), ASI09 (trust abuse)	Amazon Bedrock Guardrails, Amazon Bedrock Automated Reasoning, Amazon Bedrock AgentCore Gateway, AWS Step Functions
Data protection	Memory stores, knowledge bases, encryption, and access-controlled retrieval	ASI06 (memory poisoning)	Amazon Bedrock AgentCore Memory, AWS Key Management Service (AWS KMS), Amazon OpenSearch Service
Threat detection and response	Anomaly detection, behavioral monitoring, and automated containment	ASI10 (rogue agents), ASI08 (cascading failures)	Amazon GuardDuty, AWS Security Hub, Amazon Bedrock AgentCore Observability, Amazon CloudWatch, AWS X-Ray

Within this architecture, security controls operate at five functional layers of the agent itself:

Perceive layer: Amazon Bedrock Guardrails filters inputs and detects prompt injection attempts
Reason layer: Amazon Bedrock AgentCore Policy enforces Cedar -based authorization (an open source policy language for access control) for agent actions, while Amazon Bedrock Automated Reasoning validates outputs against domain knowledge
Act layer: Amazon Bedrock AgentCore Gateway mediates tool access with least-privilege controls; AWS WAF and Amazon API Gateway provide edge-level rate limiting and injection protection
Identity layer: Amazon Bedrock AgentCore Identity provides per-agent credentials with OAuth support
Observability layer: Amazon Bedrock AgentCore Observability sends OpenTelemetry-compatible metrics and logs to Amazon CloudWatch and traces to AWS X-Ray , while AWS CloudTrail provides API-level audit logging

Apply these security patterns regardless of how you deploy agents on AWS - whether you use fully managed Amazon Bedrock AgentCore, open source frameworks like Strands Agents , or specialized agents such as Amazon Q . The underlying AWS security services integrate across deployment models.

Mitigation strategies for inputs, identity, and human oversight

The three risks in this part share a theme: they all concern the boundary between your agent and the people and inputs it interacts with. I cover each risk, the attack anatomy, and how to address it using AWS services.

ASI01: Agent goal hijack

Agent goal hijack occurs when unauthorized users manipulate your agent's objectives, task selection, or decision pathways through prompt injection, deceptive tool outputs, unintended artifacts, or poisoned external data. Goal hijacking redirects multi-step autonomous behavior, making it particularly difficult to detect and contain.

Unauthorized users could, for instance, redirect your customer service agents to exfiltrate data, manipulate financial planning agents to approve fraudulent transactions, or hijack IT automation agents to create backdoor accounts.

Mitigation 1: Amazon Bedrock Guardrails (input filtering)

The first line of defense against goal hijacking is content filtering at the input boundary. Amazon Bedrock Guardrails provides this capability.

To implement Amazon Bedrock Guardrails for goal hijacking protection:

Create a guardrail configuration with prompt injection detection enabled.
Apply the guardrail to incoming user input using the apply_guardrail API.
Configure response handling for blocked requests.

The following code applies a guardrail with prompt injection detection to user input:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Apply a Bedrock Guardrail with prompt-injection detection to incoming input
import boto3

bedrock = boto3.client('bedrock-runtime')

def screen_input(user_input):
    response = bedrock.apply_guardrail(
        guardrailIdentifier='agent-goal-protection',
        guardrailVersion='1',
        source='INPUT',
        content=[{
            'text': {
                'text': user_input
            }
        }]
    )

    # GUARDRAIL_INTERVENED fires for any policy intervention (prompt attack,
    # denied topic, contextual grounding, PII, or word filter) - inspect the
    # response to determine which policy tripped.
    if response['action'] == 'GUARDRAIL_INTERVENED':
        log_security_event('guardrail_intervened', response)
        return "Request blocked due to security policy"
    return user_input

Enable the Prompt Attacks filter and set its strength to HIGH — this single filter detects jailbreaks, prompt injection, and (on the Standard tier) prompt-leakage attempts, catching hidden instructions and system-prompt override attempts. Note that on InvokeModel the prompt-attack filter only evaluates user input that you wrap in input tags. Define custom denied topics to block goal redirection instructions, and enable the contextual grounding check to validate responses against source data. Set the grounding and relevance thresholds based on your use case - higher values (closer to 0.99) block more aggressively but increase false positives, while lower values are more permissive.

Mitigation 2: Amazon Bedrock AgentCore Policy (Cedar-based authorization)

Input filtering alone isn't sufficient - if a prompt injection bypasses guardrails, you need a second line of defense that limits what the hijacked agent can actually do. Amazon Bedrock AgentCore Policy provides this by enforcing least-privilege authorization at the Gateway boundary, directly addressing OWASP guidelines #2 (enforce least privilege) and #4 (validate intent at runtime) for ASI01.

AgentCore Policy intercepts every tool call through the Gateway and evaluates it against Cedar policies before allowing execution. Because enforcement happens outside the agent's code, prompt injection cannot bypass it - even a hijacked agent is constrained to its permitted actions.

The following Cedar policy restricts a customer service agent to read-only operations and blocks high-impact actions that a goal hijack might attempt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Allow read-only customer service operations
permit (
    principal == AgentCore::Agent::"customer-service-agent",
    action in [
        AgentCore::Action::"GetOrderStatus",
        AgentCore::Action::"SearchKnowledgeBase"
    ],
    resource
);

// Explicitly deny high-impact actions regardless of goal manipulation
forbid (
    principal == AgentCore::Agent::"customer-service-agent",
    action in [
        AgentCore::Action::"IssueRefund",
        AgentCore::Action::"DeleteRecord",
        AgentCore::Action::"ExportCustomerData"
    ],
    resource
);

With Cedar's forbid-wins semantics, the forbid policy can never be overridden by a permit - so even if an attacker manipulates the agent's goal to attempt data exfiltration or unauthorized refunds, the policy engine blocks those actions deterministically.

Validation note: I validated the forbid-wins semantics of this policy structure in a test account. The Cedar policy correctly denies the high-impact actions even when a permit rule is present. Amazon Bedrock AgentCore, including the Gateway that enforces the policy at runtime, is generally available - see Part 2 for the Gateway setup. Validate the exact request shapes against the current API version and confirm Regional availability.

Additional controls:

Store agent system prompts in Amazon Simple Storage Service (Amazon S3) with Object Lock for immutability
Use AWS CloudTrail to detect unexpected tool invocation patterns indicating goal drift
Implement content disarm and reconstruction (CDR) using AWS Lambda for external content

Controlling what an agent is told is only part of the boundary. You also need to control who your agents are and what permissions they carry - which brings us to identity.

ASI03: Identity and privilege abuse

When your agents use dynamic trust and delegation, unauthorized inputs or misconfigured permissions can allow access escalation by manipulating delegation chains, role inheritance, and agent context.

For example, a finance agent that delegates to a database query agent with full permissions could allow unauthorized data exfiltration. In another scenario, an IT admin agent that caches credentials might inadvertently let non-admin users reuse those credentials later.

Mitigation: Amazon Bedrock AgentCore Identity

Amazon Bedrock AgentCore Identity provides identity management for your AI agents, supporting both machine-to-machine and user-delegated authentication patterns.

To configure identity management for your agents:

Choose your authentication pattern based on your use case (Two-Legged OAuth for machine-to-machine, Three-Legged OAuth for user-delegated).
Create an OAuth2 credential provider with the appropriate configuration.
Integrate the credential provider into your agent's runtime.

Two-Legged OAuth (2LO) for machine-to-machine authentication. Use this pattern when your agent needs to access resources using its own identity:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Create an OAuth2 credential provider for machine-to-machine (2LO) access
import boto3

control_client = boto3.client('bedrock-agentcore-control', region_name='us-west-2')

credential_provider = control_client.create_oauth2_credential_provider(
    name='internal-api-access',
    credentialProviderVendor='CustomOauth2',
    oauth2ProviderConfigInput={
        'customOauth2ProviderConfig': {
            'oauthDiscovery': {
                'discoveryUrl': 'https://auth.internal-api.com/.well-known/openid-configuration'
            },
            'clientId': 'agent-client',
            'clientSecret': '<client-secret>'
        }
    }
)

Three-Legged OAuth (3LO) for user-delegated access. Use this pattern when your agent needs to act on behalf of a specific user:

1
2
3
4
5
6
7
8
9
10
11
12
# Decorator-based pattern for user-delegated (3LO) access at runtime
from bedrock_agentcore.identity import requires_access_token

@requires_access_token(
    provider_name="google-calendar-provider",
    scopes=["calendar.readonly"],
    auth_flow="USER_FEDERATION",
)
async def access_calendar_on_behalf_of_user(*, access_token: str):
    # Use access_token to call the external API on behalf of the user
    headers = {"Authorization": f"Bearer {access_token}"}
    # ... make API call with delegated credentials

Use 2LO (Client Credentials) for background jobs and system-to-system communication where your agent operates under its own permissions. Use 3LO (Authorization Code) when your agent needs to access user-specific data under that user's delegated permissions.

Additional controls:

Issue short-lived credentials using AWS STS. Request a short session by passing DurationSeconds on the AssumeRole call - 900 seconds (15 minutes) is the STS minimum. (This is distinct from a role's MaxSessionDuration, whose valid range is 1-12 hours and which caps the ceiling rather than setting a short floor.)
Use AWS IAM Access Analyzer to continuously monitor privilege usage
Implement session tagging for attribute-based access control (ABAC). Note that the principal assuming the role needs the sts:TagSession permission explicitly granted in the role's trust policy - a common configuration miss

Validation note: I validated short-lived STS sessions (AssumeRole with DurationSeconds=900, the 15-minute minimum) and IAM Access Analyzer setup in a test account. Session tagging for ABAC requires the caller to hold sts:TagSession; without it, the AssumeRole call fails with AccessDenied. Grant this permission explicitly when adopting ABAC session tags.

Identity controls govern the machine-to-machine boundary. The last risk in this part concerns the boundary between your agent and the humans who trust it.

ASI09: Human-agent trust abuse

Agents establish strong trust with humans through natural language fluency and perceived expertise. This trust can be abused to influence decisions, extract sensitive information, or steer outcomes in unintended ways.

A tampered-with coding assistant might suggest a harmful one-liner, a finance copilot might recommend payment to an unauthorized party's bank, or a care assistant might recommend an inappropriate drug dosage.

Mitigation: AWS Step Functions with human-in-the-loop approval

For high-risk agent actions, AWS Step Functions with waitForTaskToken pauses execution and requires explicit human approval before proceeding:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
  "RequestHumanApproval": {
    "Type": "Task",
    "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
    "Parameters": {
      "QueueUrl": "https://sqs.<region>.amazonaws.com/111122223333/approval-queue",
      "MessageBody": {
        "TaskToken.$": "$$.Task.Token",
        "Recommendation.$": "$.recommendation",
        "RiskLevel.$": "$.riskAssessment.level"
      }
    },
    "TimeoutSeconds": 300
  }
}

Amazon Bedrock Guardrails with contextual grounding validates agent explanations against source data.

Amazon Bedrock Automated Reasoning adds factual verification to this workflow. Automated Reasoning uses logic-based algorithms and mathematical validation to check LLM outputs against domain knowledge encoded in policies - providing verifiable proof that agent responses are consistent with ground truth, rather than relying solely on statistical confidence scores.

Validation note: I validated the human-in-the-loop pattern end to end in a test account: the state machine pauses on waitForTaskToken, blocks the agent action when no approval arrives before the timeout, and proceeds when a human sends task success. Set TimeoutSeconds to a production-appropriate value (300 seconds is a reasonable default).

What to implement in week 1

This part maps to the foundational tier of the roadmap. If you do nothing else first, start here:

Amazon Bedrock Guardrails (ASI01, ASI09) - Input/output filtering protects against prompt injection, which is the root cause of several OWASP risks, making this a high-priority control
Amazon Bedrock AgentCore Identity (ASI03) - Distinct agent identities with short-lived credentials prevent privilege escalation and credential reuse
Logging and observability - Enable model invocation logging , Amazon CloudWatch, and AWS CloudTrail so you have visibility into agent behavior from day one

Coming up in Part 2

Part 1 secured the agent's front door: what it hears, who it is, and when a human signs off. Part 2 moves to what the agent runs - tool execution and runtime safety, covering ASI02 (tool misuse), ASI04 (supply chain), and ASI05 (unexpected code execution).

Additional resources

About the author

Bharadwaz Kari is a Technical Account Manager at AWS, where he helps enterprise customers operate and secure their workloads on AWS. He focuses on generative AI, security, and developer tooling. This post reflects his personal views, not those of his employer.

# amazon-bedrock-agentcore # guardrails # security # generative-ai

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Secure Your AI Agents on AWS (Part 1): Inputs, Identity, and Human Oversight

WAZ

Prerequisites

Why agentic AI requires specialized security

Understanding the OWASP Top 10 for agentic applications 2026

Defense-in-depth architecture for agentic AI

Mitigation strategies for inputs, identity, and human oversight

ASI01: Agent goal hijack

ASI03: Identity and privilege abuse

ASI09: Human-agent trust abuse

What to implement in week 1

Coming up in Part 2

Additional resources

About the author