Most organisations building on AWS now have more than one AI workload. A few have dozens. What may have started as a single proof of concept has turned into a portfolio - different teams, different use cases, different accounts, varying degrees of rigour in how each was built and deployed.
That sprawl is where governance gets hard, and it is the problem that a run of AWS announcements since re:Invent 2025 has been directly aimed at.
Created using editor
AWS was unusually direct about its positioning at re:Invent. The message was not just “here are the latest model options”. It was that Bedrock is becoming the governance and control plane for enterprise AI. A layer that makes autonomous AI deployable in organisations with high-risk profiles, not just for teams interested in running experiments. The announcements since then have put substance behind that claim.
Here’s a recap of the most important updates you need to be aware of:
Guardrails for Code (Re:Invent 2025)
As AI coding assistants spread across engineering teams, most organisations have focused on productivity gains and largely ignored the attack surface they create. The risks are plenty: malicious code injection through AI-generated outputs, PII finding its way into code structures, system prompts leaking into responses in ways that expose intellectual property or internal architecture.
Guardrails for Code, announced at re:Invent, extends content filtering into code elements (comments, variable names, string literals) and adds prompt leakage detection specifically for system prompts. It is the kind of capability that security teams will care about long before most engineering leaders have thought to ask for it.
AgentCore: Governance and observability updates
Policy and Evaluations (Re:Invent 2025)
Agentic AI is where the governance stakes are significantly higher than they are for a chatbot. An agent that says something wrong is embarrassing. An agent that takes an irreversible action (calling an API, writing records, triggering a workflow) because of a prompt injection or a misaligned instruction is a different category of problem.
AgentCore Policy and Evaluations, announced at re:Invent and reaching general availability in March 2026, address two distinct but related problems.
AgentCore Policy defines hard limits on what agents can do with tools, enforced outside the model’s reasoning loop via a gateway that intercepts every tool call before it executes. The agent cannot “think” its way around them. Policies are written in natural language, which AgentCore automatically converts to Cedar, AWS’s open-source policy language. The default behaviour is deny; permissions have to be explicitly granted. The architectural separation between agent logic and access control means that policies can sit under the control of security and compliance teams rather than the developers building the agents.
AgentCore Evaluations is the quality monitoring counterpart. It continuously samples live agent interactions and scores them against dimensions like correctness, helpfulness, tool selection accuracy, and harmfulness. There’s also the option to add custom evaluators for business-specific requirements. Results feed into CloudWatch alongside AgentCore’s observability data, with alerting when scores drop below defined thresholds.
AgentCore Optimization (April 2026)
Sitting alongside Evaluations is a new optimisation loop which involves the active analysis of production traces. This then informs suggestions for improvements to system prompts and tool descriptions, which can in turn be validated by batch evaluations or A/B tested with live traffic, allowing the ability to continuously improve agent performance.
Memory Streaming (March 2026)
Also shipping in March was AgentCore Memory Streaming - push notifications via Amazon Kinesis triggered whenever an agent updates its persistent memory. It is easy to overlook, but the governance implication is meaningful: for the first time, you have a real-time signal when agents are accumulating knowledge, making it possible to detect and respond if an agent is retaining data it should not - customer PII being the obvious concern.
Agentic AI governance has two components:
- Can you prevent the agent from doing things it should not?
- Can you detect when something is going wrong?
AgentCore Policy addresses the first, AgentCore Evaluations and Memory Streaming address the second.
Agent Registry (April 2026)
You cannot govern what you cannot see. As agent deployments scale from a handful to hundreds, organisations face a problem that is more mundane than prompt injection but arguably more dangerous: nobody knows what agents exist, who owns them, or whether they have been through any kind of approval process.
AWS Agent Registry, now in preview through AgentCore, is a governed catalogue for discovering, sharing and reusing agents, tools, skills, and MCP servers across an organisation. Records include ownership, protocols, capabilities, and invocation details. Administrators control what becomes discoverable through an approval workflow before anything is published organisation-wide. CloudTrail audit trails log access and changes. It works across agents hosted anywhere (AWS, other cloud providers, or on-premises), which is useful given that most organisations are likely not running their entire agent estate on a single platform.
Cross-account safeguards (April 2026)
The most operationally significant announcement for anyone managing AI at scale is the general availability of cross-account safeguards in Bedrock Guardrails.
The problem it solves is straightforward. If you are running AI workloads across multiple AWS accounts, which any mature organisation will be, you have historically had to configure and manage guardrails separately in each one. That means configuration drift, inconsistent policies between teams, and security functions having to verify compliance account by account. It does not scale, and in practice that means continuously retrofitting the latest security and governance rigour to existing applications.
Cross-account safeguards change the model entirely. You define a guardrail once in your AWS Organizations management account, attach it to a Bedrock policy, and it automatically applies to every model invocation across all member accounts and OUs. Member accounts cannot modify or override it. The immutability is deliberate and important. The baseline your security team signed off on stays intact regardless of what individual teams do, much like Service Control Policies.
There are two levels of enforcement that layer together:
- Organisation-level sets your baseline across the entire estate.
- Account-level lets you apply additional controls on top for accounts with specific requirements - tighter policies for accounts handling customer data, for instance, sitting on top of the organisational baseline rather than replacing it.
Where both apply, the union of configured safeguards is enforced at inference time.
There are a few implementation details worth knowing before you start. You will need to create a versioned guardrail before configuring enforcement. Versioning is what makes immutability work. You also choose between Comprehensive and Selective content guarding:
- Comprehensive applies guardrails to everything, regardless of how the calling application has tagged content.
- Selective applies only to the content that the application has explicitly flagged.
Comprehensive is the ideal default unless you have a specific reason to trust your callers’ tagging. You can also scope enforcement to include or exclude specific models, giving you the flexibility to keep internal-only models outside a policy designed for customer-facing applications.
One constraint to be aware of: At the time of writing, Automated Reasoning Checks (the formal logic-based hallucination detection) are not currently supported within cross-account enforcement. If factual verification is a hard requirement for a particular use case, that needs to be handled at the application level for now.
IAM cost allocation for Bedrock (April 2026)
Governance is not only about controlling what AI does - it is also about knowing what it costs and who is responsible for that spend. Until recently, Bedrock costs in AWS Cost Explorer were aggregated by model and region, with no easy way to attribute them to specific teams, projects or applications without building custom tooling around CloudWatch and CloudTrail logs.
Bedrock now supports cost allocation by IAM user and role, surfaced through CUR 2.0 and Cost Explorer. Tag your IAM principals with attributes like team, cost centre or project, activate them as cost allocation tags, and Bedrock inference costs flow through against those tags. If multiple applications share a single role, then the attribution becomes meaningless, but since it’s best practice to have a dedicated IAM role per application, this might prompt you to sort out your IAM structure.
It is worth noting that this is a billing feature, with a potential lag in reporting, so it tells you who spent what after the fact rather than enabling real-time controls.
Using Bedrock for a while? Book a security review
If you stood up your first Bedrock applications before Guardrails for Code or AgentCore Policy existed, those workloads may not reflect the security posture that’s now achievable.
Ask yourself: Do your current AI safety controls reflect the scale and complexity of the AI estate you actually have today?
Book a free AI security and governance review and we’ll assess where your current controls stand against what’s now achievable.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.
