Agentic AI Security SME (specialist differentiator)

Why we need it: their actual fear is agentic - inherited permissions, data aggregation, transitive identity across sub-agent chains, confused deputy. Generic IAM skills don't cover how identity and authorization break inside agent orchestration and tool-calling.

Must have

• Concrete understanding of agentic architectures: sub-agent chains, tool/function calling, MCP and A2A, and where identity collapses to a single service principal (the core failure mode).
• Ability to threat-model confused-deputy, privilege inheritance, and data-aggregation scenarios and translate them into per-hop, audience-restricted, least-privilege authorization designs.
• Externalized authorization for agents: OPA/Rego and/or Cedar, PEP/PDP placement, and an AuthZEN-style contract to keep policy portable across environments.
• Familiarity with LLM-gateway enforcement (BofA's version is called Orchestra.ai today) as a policy enforcement point, and Bedrock AgentCore Gateway / AgentCore Policy (Cedar) as the native-exploit option on Bedrock.
• Grounding in the frameworks they've reviewed (OWASP LLM/Agentic Top 10, MITRE ATLAS, NIST AI RMF) so the review traces to something defensible.

Nice to have

• Semantic-guardrail integration as pluggable signal providers (Bedrock Guardrails, Azure Content Safety) feeding deterministic authZ, not model evaluation, but knowing the boundary.

Scope:

GenAI Identity and Security Controls Framework

Situation

Customer is proactively strengthening its identity and access control posture for AI and agentic usage across the enterprise. They have engaged AWS to partner on a controls-adequacy review - assessing whether their current identity patterns are sufficiently detailed and focused to achieve their security objectives as agentic adoption scales. This is not model risk management, and not an effort to optimize for any single cloud provider.

What this is

A structured review and advisory of Customer's identity, authentication, and access-control patterns for AI/agentic usage evaluating whether they are comprehensive, appropriately scoped, and aligned to the outcomes Customer is targeting. The intended end state is an enterprise AI identity solution: control standards and reference designs that hold across environments, not a specific product build.

The challenge

As Customer expands AI and agentic tooling enterprise-wide, they are focused on ensuring identity and authorization remain robust in scenarios where traditional patterns may not hold:

• Inherited permissions and data aggregation - agentic systems operating under delegated credentials may access or act on data in ways that exceed the original authorization intent.
• Transitive identity across agent chains - sub-agents calling downstream services need bounded authority to prevent confused-deputy scenarios and unintended lateral access.
• Identity-to-model routing - ensuring the right data reaches the right model (e.g. MNPI stays on internal inference paths). This is an authentication and authorization concern, not a model-evaluation concern.

Scope (as defined by Customer)

In scope: Identity, access control, and authentication - broadly defined to include infrastructure identity, registries, non-human identity lifecycle, delegation and authority, federation, and trust boundaries.

Out of scope: Data controls, FinOps, and model evaluation / model risk management.

Target-state framing: Define the complete set of control objectives (aspirational), then govern the delta per environment with explicit, time-boxed exceptions and compensating controls. Success = every objective is either met or has a governed exception - no silent gaps.

Environment landscape

Customer operates across four model-hosting locations: on-prem GPUs, AWS Bedrock, Azure AI Foundry, and first-party direct. They do not expect consolidation - they expect continued fragmentation. The goal is control standards and designs that are environment-agnostic, while leveraging native platform strengths where available. Where a gap exists in one environment that another addresses natively, that is treated as a governed opportunity for improvement - not a blocker.

Work Customer has already completed

Customer has done significant preparatory work:

• Drafted a candidate set of solutions (~7) addressing their identified control needs. They want AWS to review these for completeness, focus, and appropriate decomposition.
• Completed a thorough review of relevant external frameworks: OWASP (LLM/Agentic), MITRE ATLAS, and NIST.

Access patterns to be scoped

Three entry points are on the table; part of the engagement is determining prioritization:

• Developer access - direct harness usage (e.g. Claude Code).
• Application usage via Orchestra - Customer's enterprise LLM gateway (AIT 74305), fronting Bedrock/Anthropic/Llama.
• Other direct access - additional paths outside the gateway.