Who is allowed to perform what action on which AWS resource, and under what conditions?

IAM can appear complicated because AWS provides several overlapping authorization mechanisms:
users, groups, roles, identity policies, resource policies, permissions boundaries, Service Control
Policies, trust policies, federation, and temporary credentials.

The easiest way to understand IAM is to begin with the basic authorization flow.

Identity
   |
   v
Authentication
   |
   v
Authorization
   |
   v
AWS Resource

When an AWS API request occurs, AWS evaluates the principal making the request, the requested
action, the target resource, applicable policies, and the context surrounding the request.

1. The Basic AWS IAM Model

Consider an application running on an EC2 instance that needs to read an object from an S3 bucket.

Application
    |
    v
EC2 Instance
    |
    | assumes
    v
IAM Role
    |
    | permissions policy
    v
Allow: s3:GetObject
    |
    v
S3 Bucket

The core concepts involved are:

2. IAM Users

An IAM user is a persistent identity created within an AWS account.

AWS Account
|
|-- IAM User: Alice
|-- IAM User: Bob
|-- IAM User: AutomationUser

An IAM user may have:

• A console password
• Access keys
• Permissions assigned through policies
• Membership in IAM groups

Historically, companies commonly created an IAM user for every employee.
Modern AWS security architecture generally favors federated identities and temporary
credentials instead.

Employee
   |
   v
Corporate Identity Provider
   |
   | SAML / Federation
   v
IAM Identity Center
   |
   v
AWS Account
   |
   v
IAM Role

This reduces the number of long-lived AWS credentials that an organization must manage.

3. IAM Groups

An IAM group is simply a collection of IAM users.

Developers Group
      |
      |-- Alice
      |-- Bob
      |-- Charlie

Policies can be attached to the group so that all members inherit those permissions.

Developers
    |
    v
DeveloperPolicy
    |
    |-- S3 Read
    |-- CloudWatch Read
    |-- Lambda Deployment

One important distinction is:

Roles can be assumed. Groups cannot.

Groups are primarily an administrative mechanism for managing IAM users.

4. IAM Roles

IAM roles are among the most important concepts in AWS security architecture.

A role is an AWS identity with permissions but normally without long-term credentials.
Instead, another principal assumes the role and receives temporary credentials.

Principal
    |
    | AssumeRole
    v
IAM Role
    |
    v
AWS STS
    |
    v
Temporary Credentials

AWS Security Token Service (STS) can return credentials containing:

• Access Key ID
• Secret Access Key
• Session Token
• Expiration time

Roles can be assumed by many different types of principals.

IAM Role
   ^
   |
   |-- IAM User
   |-- EC2
   |-- Lambda
   |-- ECS Task
   |-- Another AWS Account
   |-- Federated User
   |-- OIDC Identity
   |-- SAML Identity

5. Trust Policies vs. Permissions Policies

An IAM role has two very different authorization concepts.

Trust Policy

A trust policy answers:

Who is allowed to assume this role?

For example:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Service": "ec2.amazonaws.com"
    },
    "Action": "sts:AssumeRole"
  }]
}

This tells AWS that EC2 is trusted to assume the role.

Permissions Policy

The permissions policy answers:

What can the role do after it has been assumed?

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::financial-data/*"
  }]
}

Together:

EC2
 |
 | allowed by Trust Policy
 v
IAM Role
 |
 | allowed by Permissions Policy
 v
S3

6. IAM Policies

IAM policies are JSON documents that describe permissions.

A typical policy statement contains:

Effect
   +
Action
   +
Resource
   +
Condition (optional)

For example:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::company-data/*"
  }]
}

7. Allow, Deny, and Implicit Deny

IAM policy statements use two Effect values:

• Allow
• Deny

AWS begins with the concept of implicit deny.
If no applicable policy allows the action, the request is denied.

Implicit Deny
     |
     v
Explicit Allow?
     |
    Yes
     |
     v
Potentially Allowed
     |
     v
Explicit Deny?
  /       \
Yes       No
 |         |
DENY     ALLOW

An applicable explicit Deny generally overrides an Allow.

8. IAM Actions

An IAM action corresponds to an AWS API operation.

Examples include:

s3:GetObject
s3:PutObject

ec2:StartInstances
ec2:StopInstances

kms:Decrypt

secretsmanager:GetSecretValue

lambda:InvokeFunction

Wildcards are possible:

"Action": "s3:*"

This allows every S3 action covered by the policy.

An even broader permission is:

"Action": "*"

This should be used cautiously because it can dramatically increase the blast radius of a compromised identity.

9. Resources and ARNs

AWS policies identify resources through Amazon Resource Names (ARNs).

For example:

arn:aws:s3:::financial-data

An object inside that bucket might be:

arn:aws:s3:::financial-data/reports/report.pdf

A policy can therefore restrict access to a specific path:

"Resource": "arn:aws:s3:::financial-data/reports/*"

This enables very granular authorization.

10. IAM Conditions

Conditions make IAM policies significantly more powerful.

Instead of simply saying:

Alice may access S3.

you can create a policy that effectively says:

Alice may access S3 only when certain security conditions are satisfied.

Allow s3:GetObject

IF

MFA = true
AND
Source network = approved
AND
Resource tag = Production

IAM conditions can evaluate attributes such as:

• Source IP address
• VPC
• VPC endpoint
• MFA state
• Principal ARN
• Principal tags
• Resource tags
• AWS Region
• AWS Organization ID
• TLS usage
• Request tags

This makes IAM an important component of Zero Trust architecture.

11. Identity-Based Policies

Identity-based policies are attached to:

• IAM users
• IAM groups
• IAM roles

IAM Role
   |
   v
Identity Policy
   |
   v
Allow s3:GetObject

The policy tells AWS what actions that identity is allowed to perform.

12. Resource-Based Policies

Some AWS resources support policies attached directly to the resource.

Examples include:

• S3 bucket policies
• KMS key policies
• SQS queue policies
• SNS topic policies
• Secrets Manager resource policies
• API Gateway resource policies

IAM Role
    |
    v
S3 Bucket
    |
    v
Bucket Policy

Resource-based policies are particularly important for cross-account architectures.

13. Identity Policy vs. Resource Policy

Suppose an application in Account A needs to access an S3 bucket in Account B.

Account A                         Account B

Application
    |
    v
IAM Role  ---------------------> S3 Bucket
    |                               |
Identity Policy                 Bucket Policy

The role may have permission to call:

s3:GetObject

while the bucket policy permits a specific principal:

arn:aws:iam::111111111111:role/AppRole

The identity policy represents authorization from the caller side, while the resource policy
represents authorization from the resource side.

14. AWS-Managed and Customer-Managed Policies

AWS-Managed Policies

AWS creates and maintains these policies.

Examples include:

ReadOnlyAccess
AmazonS3ReadOnlyAccess

They are convenient but may occasionally be broader than a particular workload requires.

Customer-Managed Policies

Customer-managed policies are created and maintained by your organization.

For example:

ProductionS3InvoiceReadOnly

These policies can be designed specifically around least-privilege requirements.

15. Inline Policies

An inline policy is embedded directly inside a single IAM user, group, or role.

IAM Role
   |
   |-- Managed Policy
   |
   |-- Inline Policy

Inline policies have a one-to-one relationship with the identity.
Managed policies are usually easier to centrally maintain and reuse.

16. Permissions Boundaries

Permissions boundaries are frequently misunderstood.

A permissions boundary does not grant permissions.
Instead, it establishes the maximum identity-based permissions an IAM user or role may receive.

Suppose a role policy says:

Allow:

s3:*
ec2:*
lambda:*

but its permissions boundary only permits:

s3:*
lambda:*

The EC2 permissions are outside the boundary and therefore cannot be exercised through those identity-based permissions.

Identity Policy
      |
      v
Permissions Requested
      |
      intersect
      |
Permissions Boundary
      |
      v
Effective Maximum

Permissions boundaries are particularly useful when delegating IAM administration.

For example, developers may be allowed to create IAM roles while a required permissions boundary
ensures that those roles can never obtain unrestricted administrative permissions.

17. Service Control Policies (SCPs)

AWS Organizations provides another major authorization layer called Service Control Policies.

AWS Organization
      |
      v
Organizational Unit
      |
      v
SCP
      |
      v
AWS Account
      |
      v
IAM Roles

SCPs define organization-level permission guardrails.

For example, an SCP may prevent accounts from:

• Disabling CloudTrail
• Leaving the AWS Organization
• Using unsupported AWS Regions
• Changing security services

Even if a role inside the account has:

AdministratorAccess

an applicable explicit Deny in an SCP can still block the operation.

18. Identity Policies, Permissions Boundaries, and SCPs

Conceptually:

AWS Organization
      |
      v
     SCP
      |
      v
AWS Account
      |
      v
Permissions Boundary
      |
      v
IAM Role
      |
      v
Identity Policy
      |
      v
AWS Resource

Resource policies, trust policies, and explicit Deny statements introduce additional evaluation layers.

19. AWS STS and Temporary Credentials

AWS Security Token Service is fundamental to role-based security.

User / Application
       |
       | AssumeRole
       v
      STS
       |
       v
Temporary Credentials
       |
       v
AWS APIs

For example:

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/ProductionReadRole \
  --role-session-name audit-session

STS returns temporary credentials that expire automatically.

This is significantly preferable to distributing long-lived access keys across servers and applications.

20. EC2 IAM Roles

Applications running on EC2 should generally not store AWS access keys in files or environment variables.

Avoid:

EC2
 |
 |-- access-key.txt

Prefer:

EC2
 |
 v
Instance Profile
 |
 v
IAM Role
 |
 v
Temporary Credentials
 |
 v
AWS APIs

AWS SDKs can automatically obtain and refresh the temporary credentials associated with the role.

21. Lambda Execution Roles

AWS Lambda uses the same principle.

Lambda Function
       |
       v
Execution Role
       |
       |-- CloudWatch Logs
       |-- DynamoDB
       |-- S3
       |-- Secrets Manager

The Lambda role should contain only the permissions actually required by the function.

For example:

secretsmanager:GetSecretValue
dynamodb:PutItem
logs:CreateLogStream
logs:PutLogEvents

rather than attaching unrestricted administrative permissions.

22. Cross-Account Access

IAM roles are the standard mechanism for cross-account AWS access.

Security Account
111111111111

       |
       | AssumeRole
       v

Production Account
222222222222
       |
       v
SecurityAuditRole

The role in the Production account contains a trust policy allowing a principal from the Security
account to assume it.

This pattern is common in enterprise multi-account architectures with accounts such as:

• Security
• Networking
• Logging
• Shared Services
• Development
• Testing
• Production

23. IAM Federation

Large enterprises generally avoid maintaining IAM users for every employee.
Instead, users authenticate through an enterprise identity provider.

Employee
    |
    v
Enterprise Identity Provider
    |
    |-- Microsoft Entra ID
    |-- Okta
    |-- Other IdP
    |
    v
IAM Identity Center
    |
    v
Permission Set
    |
    v
AWS Account / IAM Role

Federation enables centralized controls such as:

• Multi-factor authentication
• Employee onboarding
• Employee termination
• Conditional access
• Centralized password policies
• Group-based access assignments

24. AWS IAM Identity Center

AWS IAM Identity Center, formerly known as AWS Single Sign-On, provides centralized workforce
access across AWS accounts.

Microsoft Entra ID
       |
       v
IAM Identity Center
       |
       |-- Developers
       |-- Security
       |-- Administrators
              |
              v
        Permission Sets
              |
        +-----+-----+
        |     |     |
        v     v     v
       DEV   TEST  PROD

Common permission sets may include:

• DeveloperAccess
• SecurityAudit
• DatabaseAdmin
• ProductionReadOnly

This model works particularly well with AWS Organizations and multi-account landing zones.

25. How AWS Evaluates an IAM Request

When an AWS request occurs, AWS evaluates multiple authorization layers.

              API Request
                   |
                   v
          Authentication Valid?
                   |
                   v
          Applicable Policies
                   |
        +----------+----------+
        |          |          |
        v          v          v
    Identity    Resource      SCP
    Policies    Policies
        |
        +---- Permissions Boundary
        |
        v
      Evaluate
        |
        v
   Explicit Deny?
     /       \
   Yes       No
    |         |
   DENY       v
        Sufficient Allow?
           /       \
         Yes       No
          |         |
        ALLOW      DENY

The exact IAM policy evaluation process has important nuances, particularly when cross-account
access, resource policies, role sessions, and permissions boundaries are involved.

However, the essential rule remains:

An applicable explicit Deny wins.

26. IAM and AWS KMS

AWS Key Management Service adds another important authorization layer.

For encrypted resources you frequently need permission to access both the resource and the encryption key.

Application
     |
     v
IAM Role
     |
     |-- s3:GetObject
     |
     |-- kms:Decrypt
             |
             v
           KMS Key

For example, a user may successfully retrieve an encrypted S3 object but still be unable to
decrypt the object because the user or role cannot use the relevant KMS key.

KMS key policies therefore deserve special attention in AWS security architectures.

27. Attribute-Based Access Control (ABAC)

AWS IAM supports tag-based authorization through Attribute-Based Access Control.

Instead of creating separate policies for every department:

FinanceUserPolicy
HRUserPolicy
EngineeringUserPolicy
MarketingUserPolicy

you can use principal and resource attributes.

For example:

Principal Tag:

Department = Finance

and:

Resource Tag:

Department = Finance

The authorization policy can then conceptually state:

Allow access when:

Principal.Department
        =
Resource.Department

ABAC can significantly reduce the number of static IAM policies required in large environments.

28. RBAC vs. ABAC

Traditional IAM architectures often rely heavily on Role-Based Access Control.

User
 |
 v
Finance Role
 |
 v
Finance Resources

ABAC makes authorization decisions based on attributes instead.

User
Department=Finance
      |
      v
Policy Evaluation
      |
      v
Resource
Department=Finance

Many mature cloud architectures combine RBAC and ABAC.

29. A Typical Enterprise AWS IAM Architecture

A large AWS organization may implement IAM roughly as follows:

                    Corporate Identity
                           |
                           v
                 IAM Identity Center
                           |
                           v
                    Permission Sets
                           |
                           v
                   AWS Organizations
                           |
                           v
                          SCPs
                           |
              +------------+------------+
              |            |            |
              v            v            v
             DEV          TEST         PROD
              |            |            |
              v            v            v
          IAM Roles     IAM Roles     IAM Roles
              |
              v
       Permissions Boundaries
              |
              v
         IAM Policies
              |
              v
       Resource Policies
              |
              v
         AWS Resources

This should normally be surrounded by security monitoring and governance services such as:

• AWS CloudTrail
• AWS Config
• IAM Access Analyzer
• AWS Security Hub
• Amazon GuardDuty
• AWS Organizations
• AWS Control Tower

30. AWS IAM Security Best Practices

Use Federation for Human Users

Avoid creating hundreds of permanent IAM users when enterprise federation through an identity
provider and IAM Identity Center can provide temporary access.

Use IAM Roles for Workloads

EC2, Lambda, ECS, EKS, and applications should generally use temporary role-based credentials
instead of embedded access keys.

Apply Least Privilege

Avoid policies such as:

"Action": "*",
"Resource": "*"

unless they are genuinely required.

Use SCPs as Enterprise Guardrails

SCPs can prevent entire classes of risky behavior across AWS Organizations.

Use Permissions Boundaries for Delegated IAM Administration

They help prevent administrators or developers from accidentally creating identities with more
permissions than intended.

Use Resource Policies Carefully

Resource-based policies are especially powerful in cross-account architectures and therefore
deserve careful review.

Use IAM Conditions

Conditions involving MFA, AWS Organizations, tags, VPC endpoints, networks, and other context can
dramatically reduce unnecessary access.

Continuously Review Permissions

IAM should not be considered a one-time configuration exercise.
Permissions should continuously be reviewed against actual usage and business requirements.

A Simple Way to Remember AWS IAM

A useful mental model is to think of IAM as five questions.

1. WHO ARE YOU?

   User
   Role
   Federated Identity

          |
          v

2. CAN YOU BECOME THIS IDENTITY?

   Authentication
   Federation
   Trust Policy

          |
          v

3. WHAT ARE YOU TRYING TO DO?

   AWS Action

          |
          v

4. WHAT ARE YOU TRYING TO DO IT TO?

   AWS Resource

          |
          v

5. ARE YOU ALLOWED?

   Identity Policy
   Resource Policy
   Permissions Boundary
   SCP
   Conditions
   Explicit Deny

Conclusion

AWS IAM becomes much easier to understand once you separate identity, authentication, role
assumption, authorization, and organization-level guardrails.

The most important concepts to understand are:

• IAM users represent long-lived identities.
• IAM groups organize users.
• IAM roles provide assumable identities with temporary credentials.
• Trust policies determine who can assume a role.
• Permissions policies determine what that role can do.
• Resource policies control access from the resource side.
• Permissions boundaries establish maximum identity permissions.
• SCPs establish organization-level guardrails.
• STS provides temporary credentials.
• IAM Identity Center provides centralized workforce access.
• ABAC allows authorization decisions based on attributes and tags.

For cloud and security architects, the next step is understanding how
IAM policies, resource policies, Service Control Policies, permissions boundaries, trust
policies, and KMS key policies interact during AWS policy evaluation.
That is where many of the most interesting—and most difficult—real-world IAM problems occur.

On AWS, such a platform can be built using services including:

• Amazon API Gateway
• Amazon Kinesis Data Streams
• AWS Lambda
• Amazon S3
• Amazon SageMaker AI
• SageMaker Feature Store
• Amazon DynamoDB
• Amazon Aurora
• Amazon Athena
• Amazon Bedrock
• Amazon Bedrock AgentCore
• Bedrock Knowledge Bases

The central architectural principle is simple:

SageMaker predicts.

Rules enforce.

Bedrock investigates and explains.

The large language model should therefore not become the system directly authorizing or rejecting financial transactions.
Instead, machine learning and deterministic policies remain in the transaction decision path while generative AI assists
fraud analysts with investigation, correlation and explanation.

1. High-Level AWS Fraud Detection Architecture

                  TRANSACTION SOURCES
                         |
                         v
                Amazon API Gateway
                         |
                         v
               Amazon Kinesis Streams
                         |
             +-----------+-----------+
             |                       |
             v                       v
         AWS Lambda                Amazon S3
             |                     Data Lake
             v
     SageMaker Feature Store
             |
             v
       SageMaker Model
             |
             v
        Fraud Score
             |
      +------+------+ 
      |      |      |
      v      v      v
   APPROVE REVIEW  HOLD
             |      |
             +---+--+
                 |
                 v
          Bedrock AgentCore
                 |
                 v
        AI Fraud Investigator
                 |
       +---------+----------+
       |         |          |
       v         v          v
   Customer   Transaction   Fraud
    History     History    Knowledge
       |         |          |
       +---------+----------+
                 |
                 v
        Investigation Report
                 |
                 v
            Fraud Analyst

2. Real-Time Transaction Ingestion

Transactions can originate from many systems:

• Credit-card payments
• ACH payments
• Wire transfers
• Mobile banking
• Online banking
• Account-profile changes
• Login events
• Device telemetry
• IP-address and geolocation telemetry

Amazon API Gateway can expose transaction APIs, while Amazon Kinesis Data Streams provides a scalable mechanism
for streaming the events through the fraud platform.

AWS Lambda can perform lightweight enrichment before the transaction is evaluated by the machine-learning model.

3. Feature Engineering: Where Much of the Fraud Intelligence Lives

A fraud model should rarely evaluate a transaction using the transaction amount alone.
The important information often comes from how the transaction differs from the customer’s historical behavior.

Consider a transaction for $7,500 when the customer’s typical transaction is approximately $310.

Current transaction = $7,500

Average transaction = $310

7,500 / 310 = 24.2

The transaction is therefore more than 24 times the customer’s normal transaction size.
That derived value may be substantially more useful to the model than the original transaction amount.

Useful fraud features might include:

amount_deviation

transaction_velocity_10m

transaction_velocity_24h

distance_from_last_transaction

new_device

new_beneficiary

ip_country_changed

failed_logins_24h

password_changed_recently

account_age

merchant_fraud_rate

historical_average_spend

device_risk_score

These features can be stored and managed through Amazon SageMaker Feature Store.

4. The SageMaker Fraud Model

For many financial-fraud problems, an excellent place to begin is a supervised model such as
XGBoost.

Fraud data is usually highly structured and tabular, making boosted decision-tree models particularly appropriate.
More sophisticated neural architectures can be introduced later if the problem and data justify the additional complexity.

A transaction presented to the model might contain features similar to:

fraud_features = {
    "amount": 7500,
    "account_age_days": 840,
    "transactions_last_10_min": 8,
    "distance_from_last_location": 1800,
    "new_device": 1,
    "new_beneficiary": 1,
    "merchant_risk_score": 0.74,
    "average_transaction": 310
}

The SageMaker model could return:

{
  "fraud_probability": 0.932,
  "risk": "HIGH"
}

5. Combine Classification with Anomaly Detection

Fraud systems do not necessarily need to rely on a single model.
A supervised fraud classifier can be combined with an anomaly-detection model.

                 Transaction
                      |
          +-----------+-----------+
          |                       |
          v                       v
   Classification Model      Anomaly Model
          |                       |
       Fraud .91              Anomaly .84
          |                       |
          +-----------+-----------+
                      |
                      v
               Combined Risk
                      |
                      v
                     .93

The first model detects patterns learned from previously identified fraud.
The anomaly model helps identify behavior that is simply unusual, including patterns the supervised model may never
have encountered before.

6. Keep the Real-Time Decision Engine Deterministic

The high-speed transaction path should remain relatively simple and deterministic.

Transaction
    |
    v
API Gateway
    |
    v
Lambda
    |
    v
Retrieve Features
    |
    v
SageMaker Endpoint
    |
    v
Fraud Probability
    |
    v
Decision Engine

A simple policy could look like this:

if fraud_score >= 0.90:
    decision = "HOLD"

elif fraud_score >= 0.70:
    decision = "MANUAL_REVIEW"

else:
    decision = "APPROVE"

A production decision engine could combine several independent signals:

Machine-Learning Score
        +
Business Rules
        +
Anomaly Score
        +
Device Risk
        +
Account Risk
        |
        v
 Final Risk Score

7. Add an AI Fraud Investigation Agent

Once a transaction crosses a fraud threshold, the case can be routed to an agentic AI investigation layer built
with Amazon Bedrock and Amazon Bedrock AgentCore.

Suppose the fraud engine reports:

Transaction: TX-88121
Fraud Probability: 93.2%
Risk Level: HIGH

The fraud investigation agent can collect evidence from multiple systems.

Fraud Investigation Agent
          |
          +-- Retrieve transaction details
          |
          +-- Retrieve transaction history
          |
          +-- Retrieve customer behavior
          |
          +-- Retrieve device history
          |
          +-- Retrieve IP/geolocation history
          |
          +-- Retrieve model explanation
          |
          +-- Search similar fraud cases
          |
          +-- Retrieve relevant fraud policies

The agent can then convert technical signals into a concise investigation report.

FRAUD INVESTIGATION REPORT

Risk: HIGH
Fraud Probability: 93.2%

Primary Indicators

1. Transaction amount is 24x the customer's normal transaction.

2. The device has never previously accessed the account.

3. The transaction originated approximately 1,800 miles
   from the customer's previous transaction location.

4. A new beneficiary was created 11 minutes before
   the transfer.

5. Eight transactions were attempted during the
   previous ten minutes.

6. Similar patterns exist in previously confirmed
   fraud cases.

Recommended Action:

HOLD TRANSACTION

Require step-up authentication and analyst review.

8. Give the Agent Tools, Not Direct Database Access

One of the most important AI-security controls is preventing the LLM from having unrestricted database access.

The agent should instead receive narrowly scoped tools such as:

get_transaction()

get_customer_profile()

get_transaction_history()

get_device_history()

get_ip_history()

get_fraud_score()

retrieve_similar_cases()

retrieve_fraud_policy()

create_investigation()

These tools can invoke Lambda functions or controlled services that enforce authorization before accessing
DynamoDB, Aurora, Athena, SageMaker or internal APIs.

The preferred pattern is:

LLM
 |
 v
Agent Tool
 |
 v
Authorization
 |
 v
Retriever / Data Access Layer
 |
 +-- RBAC / ACL enforcement
 |
 +-- Sensitive-data filtering
 |
 +-- Query validation
 |
 +-- Audit logging
 |
 v
Enterprise Data

This is effectively the traditional Data Access Layer pattern applied to enterprise AI.

9. Build a Fraud Knowledge Base with RAG

Fraud investigators require more than transactional data.
They also need institutional knowledge.

A Bedrock Knowledge Base can contain information such as:

• Fraud policies
• Historical fraud investigations
• Known attack patterns
• Investigation playbooks
• AML procedures
• Device-risk guidance
• Regulatory guidance
• Internal security procedures

             Fraud Knowledge Base
                     |
       +-------------+-------------+
       |             |             |
       v             v             v
 Fraud Policies   Past Cases   Regulations
       |             |             |
       +-------------+-------------+
                     |
                     v
                Bedrock RAG
                     |
                     v
            Investigation Agent

Retrieval-Augmented Generation, or RAG, allows the model to reason against enterprise information instead of relying
entirely on the information embedded in the foundation model.

10. Explainable Fraud Detection

A fraud analyst needs more than a score.

Instead of returning only:

Fraud Probability = 93%

the system should capture the factors that contributed to that probability.

The generative AI layer can then translate these model signals into an explanation understandable by a fraud analyst,
customer-service representative or investigator.

11. The Fraud Analyst Interface

The analyst should receive a consolidated view of the case rather than searching across numerous systems.

--------------------------------------------------

            FRAUD INVESTIGATION

Transaction: TX-88121

Fraud Score                  93%
Risk                         HIGH
Recommended Action           HOLD

--------------------------------------------------

Top Risk Indicators

New Device                   HIGH
Geo Anomaly                  HIGH
Transaction Velocity         HIGH
New Beneficiary              HIGH
Amount Anomaly               MEDIUM

--------------------------------------------------

AI Investigation

The transaction differs significantly from the
customer's historical behavior...

[View Evidence]

--------------------------------------------------

     APPROVE      HOLD      CONFIRM FRAUD

--------------------------------------------------

12. Create a Continuous Fraud-Learning Loop

The fraud analyst’s decision should not disappear after the investigation is complete.
It represents extremely useful labeled training data.

AI Prediction
     |
     v
Analyst Decision
     |
     v
Confirmed Fraud
or
Legitimate Transaction
     |
     v
Training Dataset
     |
     v
Model Evaluation
     |
     v
SageMaker Retraining

Over time, analyst decisions create a feedback mechanism through which the fraud model can learn from new attack
techniques and changing customer behavior.

13. The Complete AWS Architecture

                   BANKING / PAYMENT SYSTEMS
                             |
                             v
                    Amazon API Gateway
                             |
                             v
                   Amazon Kinesis Streams
                             |
               +-------------+-------------+
               |                           |
               v                           v
           AWS Lambda                    Amazon S3
               |                         Data Lake
               v                            |
     SageMaker Feature Store                |
               |                            |
               v                            v
        SageMaker Endpoint             Glue / Athena
               |
               v
         Fraud Probability
               |
               v
         Decision Engine
               |
       +-------+--------+
       |       |        |
       v       v        v
    APPROVE  REVIEW    HOLD
               |        |
               +---+----+
                   |
                   v
          Amazon Bedrock AgentCore
                   |
                   v
           Fraud Investigator
                   |
       +-----------+------------+
       |           |            |
       v           v            v
   Agent Tools   Knowledge    SageMaker
                   Base       Explanation
       |
  +----+-----+------+
  |          |      |
  v          v      v
DynamoDB   Aurora  Athena
                   |
                   v
          Investigation Report
                   |
                   v
             Fraud Analyst
                   |
                   v
           Analyst Decision
                   |
                   v
             Training Data
                   |
                   v
         SageMaker Retraining

14. Three Layers of Fraud Intelligence

Perhaps the most useful way to understand the architecture is as three separate intelligence layers.

Layer 1: Deterministic Rules

New Beneficiary
+
Large Transfer
+
Recently Changed Password
=
Require Additional Verification

Rules provide predictable security controls for conditions the institution already understands.

Layer 2: Machine Learning

Customer Behavior
+
Transaction History
+
Device Signals
+
Velocity
+
Geography
       |
       v
SageMaker
       |
       v
Fraud Probability = 93%

Machine learning identifies combinations of signals that are too complex to represent through manually maintained rules.

Layer 3: Agentic AI

Fraud Alert
    |
    v
Bedrock Agent
    |
    +-- Why is this suspicious?
    |
    +-- What evidence supports the alert?
    |
    +-- Have we seen similar cases?
    |
    +-- What policy applies?
    |
    +-- What should the analyst investigate?

This layer is not intended to replace the fraud model.
Its role is to investigate, correlate, retrieve, summarize and explain.

15. Why the LLM Should Not Directly Approve Financial Transactions

It may be tempting to place a generative AI model directly in the transaction-decision path.
That would usually be a poor architecture.

Generative models are probabilistic systems.
Financial authorization controls frequently require deterministic behavior, clear thresholds, explainability,
auditability and repeatability.

A safer separation of responsibilities is:

16. Moving Toward a Multi-Agent Fraud Platform

The architecture can eventually evolve beyond a single fraud agent.
A financial institution could create specialized agents responsible for different categories of fraud.

                 FRAUD SUPERVISOR AGENT
                          |
          +---------------+---------------+
          |               |               |
          v               v               v
    Transaction       Account        Identity /
    Fraud Agent       Behavior       Takeover Agent
                      Agent
          |               |               |
          +---------------+---------------+
                          |
                          v
                Correlated Risk View
                          |
                          v
                 Fraud Investigation

For example:

• Transaction Fraud Agent: Investigates unusual payments, transfers and merchant activity.
• Account Behavior Agent: Looks for changes in transaction velocity, beneficiaries and account behavior.
• Identity/Account-Takeover Agent: Investigates device, login, authentication and geolocation anomalies.
• Fraud Supervisor Agent: Correlates findings and produces a unified case for the investigator.

This transforms the architecture from a traditional fraud-scoring system into an
agentic fraud operations platform.

Conclusion

The next generation of fraud detection is unlikely to be built around a single AI model.
Instead, it will combine multiple forms of intelligence.

Rules
  +
Machine Learning
  +
Anomaly Detection
  +
Enterprise Data
  +
RAG
  +
Agentic AI
  +
Human Investigation

Amazon SageMaker can determine whether a transaction resembles fraudulent behavior.
Traditional rules can enforce known financial controls.
Amazon Bedrock and AgentCore can investigate why the transaction was flagged, correlate evidence,
retrieve relevant institutional knowledge and explain the case to an analyst.

The architectural principle remains:

SageMaker predicts. Rules enforce. Bedrock investigates.

That separation creates a system that can take advantage of modern generative and agentic AI without placing
a probabilistic language model directly in control of financial authorization decisions.