--- title: "Anomity Integrates with AWS Bedrock | Anomity Blog" description: "Anomity now reads Bedrock, Bedrock Agents, knowledge bases and AgentCore across your AWS accounts and flags missing prompt logging and guardrails." url: "https://anomity.ai/blog/anomity-aws-bedrock-integration/" source: html --- Anomity Integrates with AWS Bedrock Contents - Why AWS Bedrock, and why now - What the connector reads - What it flags - How it authenticates: a role, not a secret - Built to say what it could not see - How Anomity and AWS fit together - Frequently asked questions 0% 6 min read Share - X.com - LinkedIn - Email - Copy URL - Copy markdown [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Anomity Integrates with AWS Bedrock ![Anomity robot illustrating Anomity Integrates with AWS Bedrock] Company # Anomity Integrates with AWS Bedrock Anomity Research Anomity Research · Sep 10, 2026 · 6 min read Share: Copied TL;DR - Anomity now connects to AWS . Across one account or a whole AWS Organization, the connector reads Bedrock model access and governance settings, Bedrock Agents , Knowledge Bases and the data sources behind them, Flows, and AgentCore gateways, runtimes, memory, browsers, code interpreters and credential providers. - It is Anomity's first cloud-infrastructure source. Google Workspace and GitHub answer what employees authorized; AWS answers what AI the company runs in its own cloud account, and whether it is governed. None of it touches a laptop. - A new cloud AI posture policy flags prompt logging switched off, no guardrail or none enforced account-wide, hosted agents with no guardrail, cross-region inference, resources outside approved regions, knowledge bases over content stores you have not approved, and static API keys in the AgentCore credential vault. - Setup is an account ID and two buttons: a CloudFormation quick-create link deploys a read-only role in your own console, with an ExternalId Anomity mints. No AWS secret is stored , and revoking access is deleting the role. - Everything that could not be read is reported as a gap, never as clean: an account Anomity could not assume into appears as its own row. - Findings route like every other Anomity finding: to your SIEM, Slack or ticketing. Anomity now integrates with **AWS**. Connect one AWS account or a whole AWS Organization and Anomity reads the AI running inside it: **Bedrock** model access and governance settings, **Bedrock Agents**, **Knowledge Bases** and the data sources feeding them, Flows, and **AgentCore** gateways, runtimes, memory, browsers, code interpreters and credential providers. All of it lands in the AI Applications inventory, and a new cloud AI posture policy turns the gaps into findings. The connector is available today from Settings, under Integrations. This post covers why we built it, what it reads, what it flags, and how a read-only role gets deployed in two clicks without Anomity ever holding an AWS secret. ## Why AWS Bedrock, and why now Anomity's first cloud discovery sources, [Google Workspace](https://anomity.ai/blog/anomity-google-workspace-integration/) and [GitHub](https://anomity.ai/blog/anomity-github-integration/), answer one question: what did employees authorize against company data. AWS answers a different one: **what AI is the company running in its own cloud account, and is it governed?** A Bedrock agent with an action group that can call Lambda, a knowledge base built over SharePoint, an AgentCore gateway exposing tools to agents: none of these touch a managed laptop, so no endpoint sensor will ever see them. They matter for the same reasons the endpoint does. An AgentCore gateway is an MCP server in all but name, which makes it part of the inventory we described in [how to build an MCP server registry](https://anomity.ai/blog/how-to-build-an-mcp-server-registry/). A knowledge base is the cloud version of an agent's context footprint, the subject of our guide to [auditing the data sources AI agents access](https://anomity.ai/blog/auditing-ai-agent-data-sources/). And invocation logging is the difference between having an [audit trail for AI agents](https://anomity.ai/blog/ai-agent-audit-trail-and-logging-guide/) and having none. ## What the connector reads Every call the role allows is a List or a Get. The connector records one row per account and region for the Bedrock service itself, carrying the account-level posture, and one row per resource below it. From AWS What Anomity records **Bedrock posture** Whether model invocation logging is on and where it goes, the guardrails defined and whether any is enforced account-wide, the account's data retention mode, cross-region inference profiles and prompt routers. The foundation models offered in each region are counted, and which of them have access granted is an opt-in check. **Bedrock Agents** Each agent's action groups (which is where its Lambda reach lives), attached knowledge bases, collaborators, and whether it has a guardrail of its own. **Knowledge Bases** Each knowledge base and the **type** of every data source feeding it: S3, SharePoint, Confluence, Salesforce or web. This is what a model can retrieve from. **Flows and models** Bedrock Flows, plus custom, imported and marketplace models. **AgentCore** Gateways (which are MCP servers), runtimes, memory stores, browsers and code interpreters, and whether credential providers hold a static API key or use OAuth. **Accounts not read** Any account Anomity could not assume into appears as its own row, so a gap in coverage is visible rather than silent. Rows are classified from what AWS reports about them, not from their names. A knowledge base called 'hr-handbook' carries no vendor token, and guessing one would put a fabricated claim in a security inventory. ## What it flags AWS posture runs through a new **cloud AI posture** policy type, with a seeded template, **Bedrock account with no prompt logging or guardrail**, at high severity. Each check can be switched on or off per policy. - Invocation logging off. No prompt or response sent to this model service is recorded anywhere, so there is nothing to investigate against. - No guardrail. Nothing filters prompts or responses in this account and region. - Guardrails not enforced. Guardrails exist, but none is enforced account-wide, so applying one is left to whoever writes the calling code. - Hosted agent with no guardrail. A Bedrock agent runs with no guardrail attached, independent of any account default. - Cross-region inference. Requests made in one region can be served by a model in another, so inference data leaves the region. - Region not allowed. An AI resource runs outside the regions you list as approved. - Data source not allowed. A knowledge base draws on a content store you have not approved as a model corpus, for example SharePoint or Confluence. - Static credential. A long-lived third-party API key sits in the AgentCore credential vault. Off by default. - Discovery gap. One or more accounts could not be read, so the absence of findings there is not evidence they are clean. Most of these are governance failures with no personal data in them, which is why they get their own policy type rather than riding on the PII-based policy that governs OAuth apps. A knowledge base over SharePoint is the exception: it genuinely exposes personal data, so it is rated high on PII and fires both. Findings route to the SIEM, Slack or a ticket in [Jira](https://anomity.ai/blog/anomity-jira-integration/), like every other Anomity finding, and the same issue across many accounts groups into one ticket naming them rather than one ticket each. ## How it authenticates: a role, not a secret Anomity never holds an AWS access key. You deploy a read-only IAM role in your own account that trusts Anomity's AWS principal under an ExternalId unique to your connector, and Anomity assumes it for each sync. - In Anomity, add an AWS connector. Choose single account or organization coverage, enter the 12-digit account ID, and pick regions. No role ARN to type: the role name is fixed by the template, so Anomity derives it. - Save. Anomity mints the ExternalId and the dialog moves to step two instead of closing. - Click Deploy role in AWS . A CloudFormation quick-create link opens your own console with the template, stack name, Anomity's principal and your ExternalId already filled in. Create the stack. - Click Test connection in the same dialog, then sync. The exact permissions the role grants are listed in the connect dialog before you deploy anything: Bedrock and AgentCore List and Get calls, and organizations:ListAccounts for organization coverage. The role cannot invoke a model or change a resource. The ExternalId is minted by Anomity and any value a client sends is ignored, because a caller who could choose it could pair another tenant's role with that tenant's ExternalId. That is the whole confused-deputy control. For organization coverage, Anomity assumes a role in your management account, which lists the active member accounts and assumes a read-only member role in each, deployed with a StackSet. Anomity's principal appears in exactly one trust policy, so revoking it is one change in one account rather than a redeploy across every member. The management role can assume only the named member role, never an arbitrary role in your organization. ## Built to say what it could not see An organization sweep is accounts times regions times a dozen or so API calls, and some of them will fail for ordinary reasons: a role that omits AgentCore, a region where AgentCore does not exist, a setting that is not available everywhere. Each call is independent, so a refusal costs one fact and never the sweep. An account that cannot be assumed into becomes a visible row. If every account fails, the sync fails, because reporting zero findings with a green status would be the worst possible answer. And the per-model access check, which costs one call per model per region, is off by default; when it is off, the service row says so instead of implying the fact was checked. We verified the connector end to end against a live AWS account, including the one-click customer path from account ID to Deploy role to Test to Sync, and creating a guardrail and a knowledge base mid-test to watch findings resolve and appear. ## How Anomity and AWS fit together AWS provides the controls: IAM, guardrails, invocation logging, regions. Anomity checks whether those controls are switched on across every account and region, and puts the AI running in AWS in the same inventory as everything else. The Endpoint Sensor covers agents, MCPs, extensions, skills, secrets, hooks, CLIs and local LLM runtimes on each managed device and decides allow, deny or log at the agent hook before a tool call runs; the Browser Sensor covers AI web services; and cloud discovery now spans SaaS grants and cloud accounts. The same cloud AI posture policy extends to the other places companies run models: [Azure AI Foundry](https://anomity.ai/blog/anomity-azure-ai-foundry-integration/) answers the same questions through the same policy, so 'require prompt logging' is written once rather than once per cloud, and [Google Cloud Vertex AI](https://anomity.ai/blog/anomity-google-cloud-vertex-ai-integration/) joins it, as does the AI Gateway layer in [Cloudflare](https://anomity.ai/blog/anomity-cloudflare-integration/). Direct vendor accounts are covered from the [OpenAI API platform](https://anomity.ai/blog/anomity-openai-api-platform-integration/) and the [Anthropic Console](https://anomity.ai/blog/anomity-anthropic-console-integration/). Anomity collects metadata only and is SOC 2 Type II attested. To see the AI running in your own AWS accounts, [book a 30-minute demo](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions What does the Anomity AWS Bedrock integration do? It connects one AWS account, or every account in an AWS Organization, to Anomity's cloud discovery. The connector reads the AI resources running there: Bedrock model access, invocation logging, guardrails, data retention, cross-region inference profiles and prompt routers; Bedrock Agents with their action groups, knowledge bases, collaborators and guardrails; knowledge bases and the types of data source feeding them; Flows; custom, imported and marketplace models; and AgentCore gateways, runtimes, memory stores, browsers, code interpreters and credential providers. Each becomes a row in the AI Applications inventory, and a cloud AI posture policy turns governance gaps into findings. Does Anomity store AWS credentials? No. You deploy a read-only IAM role in your own account that trusts Anomity's AWS principal under an ExternalId unique to your connector. Anomity assumes that role for each sync and holds no access key or secret. Revoking access is deleting the role or the stack that created it. What permissions does the role grant? List and Get calls only, across Bedrock and Bedrock AgentCore, plus organizations:ListAccounts for organization coverage. The full list is shown in the connect dialog before you deploy anything. The role cannot invoke a model, read a prompt, or change any resource. Why is the ExternalId generated by Anomity rather than by me? Because that is what makes it a confused-deputy control. If a caller could choose the ExternalId, one tenant could name another tenant's role and that tenant's ExternalId and have Anomity read an account that is not theirs. Anomity mints it on save, ignores any value sent by a client, and never re-mints it on update. It is an identifier rather than a secret, which is why it can be pre-filled in the CloudFormation link. How does organization coverage work? Anomity's principal assumes a role in your management account, which lists the active member accounts and assumes a read-only member role in each, deployed with a StackSet. Anomity's principal appears in exactly one trust policy, so rotating or revoking it is one change in one account. The management role can only assume the named member role, not arbitrary roles in your organization, and suspended accounts are skipped. What happens if Anomity cannot read part of an account? Each API call is independent, so a call your role does not allow, or a service that does not exist in a region, costs one fact and never the sweep. An account Anomity cannot assume into appears as its own row saying so, and the posture policy can flag it, because no findings for an account and an account that could not be read must never look the same. If no account at all can be read, the sync fails rather than reporting a clean result. Does this replace AWS Security Hub or Bedrock's own controls? No. Bedrock guardrails, invocation logging and IAM are the controls; Anomity checks whether they are switched on, across every account and region, and puts the AI running in AWS in the same inventory as the AI on your endpoints, in the browser and in your SaaS. It complements your cloud security posture, SIEM, EDR and DLP tooling rather than replacing it. ## Related posts [Company ### Anomity Integrates with Azure AI Foundry Anomity now reads Azure AI Foundry and Azure OpenAI accounts across your subscriptions and flags missing logging, content filters and API-key access. Anomity Research · Sep 10, 2026 · 4 min](https://anomity.ai/blog/anomity-azure-ai-foundry-integration/) [Company ### Anomity Integrates with Google Cloud Vertex AI Anomity now reads Vertex AI endpoints, Agent Engine agents, RAG corpora and Gemini Enterprise apps in your Google Cloud projects, with no key to hand over. Anomity Research · Sep 11, 2026 · 7 min](https://anomity.ai/blog/anomity-google-cloud-vertex-ai-integration/) [Company ### Anomity Integrates with GitHub Anomity now reads the GitHub Apps installed on your org, Copilot seats and org webhooks, and risk-scores the AI tools holding access to your code. Anomity Research · Jul 6, 2026 · 6 min](https://anomity.ai/blog/anomity-github-integration/) ## Structured data ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Anomity Integrates with AWS Bedrock", "description": "Anomity now reads Bedrock, Bedrock Agents, knowledge bases and AgentCore across your AWS accounts and flags missing prompt logging and guardrails.", "datePublished": "2026-09-10", "dateModified": "2026-09-10", "author": { "@type": "Person", "name": "Anomity Research", "jobTitle": "Anomity Research" }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/anomity-logo.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/anomity-aws-bedrock-integration/", "relatedLink": [ "https://anomity.ai/blog/anomity-azure-ai-foundry-integration/", "https://anomity.ai/blog/anomity-google-cloud-vertex-ai-integration/", "https://anomity.ai/blog/anomity-github-integration/" ] }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/anomity-aws-bedrock-integration.png", "width": 1200, "height": 630 }, "articleSection": "Company", "wordCount": 1279, "timeRequired": "PT6M", "inLanguage": "en", "url": "https://anomity.ai/blog/anomity-aws-bedrock-integration/", "keywords": "AWS Bedrock AI posture discovery, AWS, Amazon Bedrock, AgentCore, Integrations, Cloud Discovery, Cloud AI Posture, Guardrails" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What does the Anomity AWS Bedrock integration do?", "acceptedAnswer": { "@type": "Answer", "text": "It connects one AWS account, or every account in an AWS Organization, to Anomity's cloud discovery. The connector reads the AI resources running there: Bedrock model access, invocation logging, guardrails, data retention, cross-region inference profiles and prompt routers; Bedrock Agents with their action groups, knowledge bases, collaborators and guardrails; knowledge bases and the types of data source feeding them; Flows; custom, imported and marketplace models; and AgentCore gateways, runtimes, memory stores, browsers, code interpreters and credential providers. Each becomes a row in the AI Applications inventory, and a cloud AI posture policy turns governance gaps into findings." } }, { "@type": "Question", "name": "Does Anomity store AWS credentials?", "acceptedAnswer": { "@type": "Answer", "text": "No. You deploy a read-only IAM role in your own account that trusts Anomity's AWS principal under an ExternalId unique to your connector. Anomity assumes that role for each sync and holds no access key or secret. Revoking access is deleting the role or the stack that created it." } }, { "@type": "Question", "name": "What permissions does the role grant?", "acceptedAnswer": { "@type": "Answer", "text": "List and Get calls only, across Bedrock and Bedrock AgentCore, plus organizations:ListAccounts for organization coverage. The full list is shown in the connect dialog before you deploy anything. The role cannot invoke a model, read a prompt, or change any resource." } }, { "@type": "Question", "name": "Why is the ExternalId generated by Anomity rather than by me?", "acceptedAnswer": { "@type": "Answer", "text": "Because that is what makes it a confused-deputy control. If a caller could choose the ExternalId, one tenant could name another tenant's role and that tenant's ExternalId and have Anomity read an account that is not theirs. Anomity mints it on save, ignores any value sent by a client, and never re-mints it on update. It is an identifier rather than a secret, which is why it can be pre-filled in the CloudFormation link." } }, { "@type": "Question", "name": "How does organization coverage work?", "acceptedAnswer": { "@type": "Answer", "text": "Anomity's principal assumes a role in your management account, which lists the active member accounts and assumes a read-only member role in each, deployed with a StackSet. Anomity's principal appears in exactly one trust policy, so rotating or revoking it is one change in one account. The management role can only assume the named member role, not arbitrary roles in your organization, and suspended accounts are skipped." } }, { "@type": "Question", "name": "What happens if Anomity cannot read part of an account?", "acceptedAnswer": { "@type": "Answer", "text": "Each API call is independent, so a call your role does not allow, or a service that does not exist in a region, costs one fact and never the sweep. An account Anomity cannot assume into appears as its own row saying so, and the posture policy can flag it, because no findings for an account and an account that could not be read must never look the same. If no account at all can be read, the sync fails rather than reporting a clean result." } }, { "@type": "Question", "name": "Does this replace AWS Security Hub or Bedrock's own controls?", "acceptedAnswer": { "@type": "Answer", "text": "No. Bedrock guardrails, invocation logging and IAM are the controls; Anomity checks whether they are switched on, across every account and region, and puts the AI running in AWS in the same inventory as the AI on your endpoints, in the browser and in your SaaS. It complements your cloud security posture, SIEM, EDR and DLP tooling rather than replacing it." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Anomity Integrates with AWS Bedrock", "item": "https://anomity.ai/blog/anomity-aws-bedrock-integration/" } ] } ```