Cloud Collectors

Register and deploy a Pangea AIDR Cloud collector to ingest AI-related telemetry from supported cloud services such as AWS.

Register collector

1. In the left sidebar, click + Collector (or + if you are on the Visibility page) to register a new collector.

2. Choose Cloud as the collector type, then select a provider integration (for example, AWS), and click Next.

3. On the Add a Collector screen, enter a descriptive name and optionally assign input and output policies:

   • Collector Name - Label that will appear in dashboards and reports
   • Input Policy (optional) - Policy applied to incoming data
   • Output Policy (optional) - Policy applied to model responses

   If you assign a policy, you can also enable the Async Report Only mode for input or output:

   • Async Report Only - Runs detections for visibility and reporting only, without enforcement or delays in the data path
   note

   • Assigning a policy determines which detections run on the data sent to AIDR, making results available for analysis, alerting, and integration with enforcement points. Policies can detect malicious activity, sensitive data exposure, topic violations, and other AI-specific risks. You can reuse existing policies or create new ones on the Policies page.

   • If No Policy, Log Only is selected, AIDR records activity for visibility and analysis, but does not apply any detection rules in the data path.

Deploy collector

To deploy a Cloud collector, follow the instructions for your chosen cloud integration in the collector’s Install tab. Additional setup details are provided below.

AWS

The AWS integration uses a Lambda function to generate pre-signed URLs for Amazon S3 objects containing Amazon Bedrock model invocation logs. These URLs are sent to the AIDR service, which retrieves and processes the logs. The resulting event data appears on the Findings and Visibility pages in the AIDR console.

The collector’s Install tab provides copyable CLI commands that you can run with the aws CLI to:

1. Enable Amazon Bedrock model invocation logging to an S3 bucket.
2. Create and configure a Lambda function that forwards log references to AIDR.
3. Add an S3 trigger to invoke the Lambda function when new log files are written.

These commands can be used in environments where the aws CLI is installed and configured with the necessary permissions, or in automation workflows such as Terraform.

The following walkthrough shows how to complete the same setup using the AWS Management Console.

Prerequisites

To perform this setup, you need an AWS account with permissions to:

• Enable Amazon Bedrock model invocation logging (per region).
• Create and manage IAM roles and policies.
• Create and configure a Lambda function.
• Use iam:PassRole to assign the Lambda execution role during function creation.
• Create/configure S3 buckets and bucket notifications.

The Lambda function runs with a minimal execution role that can write CloudWatch Logs and sign S3 GetObject URLs.

Enable Amazon Bedrock model invocation logging to S3

1. Create an S3 bucket to store Amazon Bedrock model invocation logs. For example, s3://aidr-<aidr-organization-name>-<aidr-collector-name>-<aws-account-id>-<aws-region>/bedrock-logs.
2. In the AWS Management Console, open Amazon Bedrock and choose Settings.
3. Enable Model invocation logging.
4. For the logging destination, select S3 only.
5. In the S3 location field, enter the bucket name and optional prefix.
6. Save the configuration.

Create Lambda function to forward events to AIDR

1. In the Install tab on the collector page in the AIDR console, download the lambda_function.zip file using the Download Lambda Function (ZIP) link.
2. In the AWS Management Console, open the Lambda service and click Create function.
3. On the Create function page:
   • Select Author from scratch.
   • Enter a Function name, for example: aidr-<aidr-organization-name>-<aidr-collector-name>-<aws-region>.
   • Select a Python version as the Runtime.
   • Under Permissions, expand Change default execution role and select Create a new role with basic Lambda permissions.
   • Click Create function.
4. On the function details page, under Code source:
   • Upload the lambda_function.zip file.
   • Add the following environment variables using values from the collector page in the AIDR console:
     • AIDR_BASE_URL - AIDR API base URL, shown in the Set Environment Variables section of the Install tab. For example, https://aidr.aws.us-west-2.pangea.cloud.
     • API_KEY - Current token from the Config tab.

Add permissions to Lambda function role

When you use the Change default execution role option while creating the Lambda function, AWS will:

• Create a new IAM role and assign it to the Lambda function.
• Add a trust policy for lambda.amazonaws.com to the role (so the Lambda service can assume it).
• Attach the AWSLambdaBasicExecutionRole managed policy to the role (so the function can write execution logs to CloudWatch).

To allow the pre-signed URLs generated by the Lambda function to work, add a policy to the Lambda role that grants s3:GetObject on the Bedrock log bucket and prefix.

On the Lambda function page:

1. Click the Configuration tab, then select Permissions in the left sidebar.

2. Click the role name to open its configuration in the IAM console.

3. In the Permissions screen, click Add permissions and create an inline policy using the following template in the JSON editor. Replace the placeholders with your S3 bucket name and prefix:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": ["s3:GetObject"],
         "Resource": ["arn:aws:s3:::<S3-bucket>/<S3-prefix>/*"]
       }
     ]
   }

note

Alternatively, you can pre-create an IAM role with the required trust and permission policies and assign it to the Lambda function during creation. The trust policy must allow lambda.amazonaws.com as the principal so that the Lambda service can assume the role.

Example trust policy

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

Instead of defining permissions inline, you can also create customer-managed policies and attach them to the role.

Example CloudWatch permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "logs:CreateLogGroup",
      "Resource": "arn:aws:logs:<AWS-region>:<AWS-account-id>:*"
    },
    {
      "Effect": "Allow",
      "Action": ["logs:CreateLogStream", "logs:PutLogEvents"],
      "Resource": [
        "arn:aws:logs:<AWS-region>:<AWS-account-id>:log-group:/aws/lambda/<Lambda-function-name>:*"
      ]
    }
  ]
}

Example S3 access permission policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::<S3-bucket>/<S3-prefix>/*"]
    }
  ]
}

Add trigger to Lambda function

On the Lambda function page:

1. Open the Configuration tab and select Triggers in the left sidebar.
2. Click Add trigger.
3. Select S3 as the trigger source.
4. In the Bucket field, select the S3 bucket you configured for Amazon Bedrock model invocation logs.
5. In the Event type field, select All object create events.
6. In the Prefix field, enter the prefix you configured for Bedrock logs; for example: bedrock-logs/.
7. In the Suffix field, enter .gz.
8. Acknowledge the warning under Recursive invocation by checking the box.
9. Click Add.

Test collector

To test the collector deployment, open the Amazon Bedrock service in the AWS Management Console and use the text playground to invoke a model. If everything is configured correctly, you should see events on the Findings page in the AIDR console after a few minutes delay.

You can view the Lambda function’s invocation metrics and logs in the Monitor tab.

Troubleshooting

If you don't see new events in the AIDR console, go to the Lambda function's Monitor tab and click View logs in CloudWatch.

The CloudWatch logs should show the Lambda sending a pre-signed URL to AIDR and receiving a 202 Accepted response. If you see 403 Forbidden responses, check that the API key and AIDR API base URL are correctly set in the Lambda function's environment variables.

To check the status of an asynchronous request, open the URL returned in the result.location field of the 202 response. Send a GET request and authorize it with the collector's API key as a Bearer token.

Example cURL to check request status

curl --location 'https://aidr.aws.us-west-2.pangea.cloud/request/prq_dioqsgbojz5rg3xkqydahqer3vupl74i' \
--header 'Authorization: Bearer pts_xx7rw2o...iaq63oo'

Example successful response

{
  "request_id": "prq_dioqsgbojz5rg3xkqydahqer3vupl74i",
  "request_time": "2025-09-23T17:34:04.118110Z",
  "response_time": "2025-09-23T17:34:04.333419Z",
  "status": "Success",
  "summary": "Successfully processed the CSP logs",
  "result": {}
}

A Success status means AIDR was able to read the logs from the pre-signed URL.