Skip to main content
A new era of cloud security. A new category.

Secure AI Agents with Controls Built into the Cloud

Give agents room to work within the permissions your security team approves. Native brings together cloud and agent-platform controls for identities, tools, networks and data across AWS, Google Cloud, Azure and OCI, with coverage that reflects what each platform supports.

Book a demoSee your agents

Give Agents Freedom Within Defined Limits

Managed agent platforms give AI systems a place to run, an identity, access to tools and sometimes long-lived memory. As those systems become part of real business workflows, a prompt or a line of application code is a fragile place to carry every security decision. The cloud and agent platform already have ways to limit access outside the agent’s own reasoning. Agent Boundaries puts those controls to work. It is Native’s expansion from secure cloud infrastructure into the next layer of AI infrastructure security, with broader runtime, Kubernetes and data-platform enforcement part of our longer-term direction.

The Problem

The Controls Are There. Keeping Them Aligned Takes Work.

AWS, Google, Microsoft and Oracle offer different ways to govern agent identities, networks, memory and tool access. Security teams have to understand the controls on each platform, work out what a proposed change might interrupt and keep the settings consistent as more agents appear. On AWS, for example, permission to update a gateway also allows someone to change its policy engine to log-only or remove it entirely. A workable security architecture needs to account for that administration path as well as the tool permissions themselves.

Agent controls across four clouds: tool-call policy active, an AgentCore policy engine switched to log-only, caller authorization active, network isolation drifted

Four Parts of an Agent’s Operating Environment

How agents are built

  • Agents run on private networks.

    Agent runtimes, code sandboxes and browsers are configured to stay off the public network.

  • Every gateway requires approved sign-in.

    No gateway accepts anonymous calls, and each one only trusts tokens from an identity provider your organization approved, such as Okta or Microsoft Entra ID.

  • Tool credentials stay with the broker.

    Agents use brokered access instead of holding raw API keys, and MCP servers come from a reviewed list.

  • Tool authorization stays enabled.

    Gateway policy engines remain in enforcement mode.

What agents may do

  • Tool-call rules are defined as code.

    Specify which agents can use particular tools, which actions are prohibited and which require approval.

  • Tool outputs are screened.

    Responses from tools are checked for sensitive data before reaching the agent.

Who agents are and what they reach

  • Only approved callers can invoke agents.

    Invocation isn’t open to anyone by default.

  • Agent runtimes sit behind gateways.

    Requests reach the runtime through its designated gateway.

  • Agent identities have limited authority.

    Each agent’s role gets only the access its job needs, can’t be used by a person and stays separate from human accounts.

What agents remember and emit

  • Memory follows your retention rules.

    You decide how long agent memory is kept and which destinations are approved.

  • Agent activity is recorded.

    Tool-call logs make it possible to review and replay previous activity.

  • Existing cloud policies extend to agents.

    Rules for customer-managed keys, third-party access and credential age apply to agent resources as well.

Amazon Bedrock AgentCore · Gemini Enterprise Agent Platform · Microsoft Foundry Agent Service · OCI Generative AI Agents

Map the Agent Environment, Then Apply the Right Controls

See

Native maps the agent runtimes, gateways, tools and identities it discovers across your accounts, giving your team a view of how they connect.

Declare

Choose a boundary from Native’s managed library or describe it in plain language, such as “support agents may read tickets but never issue refunds.” Native maps that policy to the tools actually configured on your gateways.

Simulate

Before anything is enforced, Native shows what the rule would have blocked and who it would have affected. It uses your audit logs and current state, plus each platform’s own test mode where one exists: log-only on AWS, dry run on Google Cloud, audit mode on Azure and inform mode on OCI.

Enforce and keep

After approval, Native applies the supported provider-native controls and watches for changes. Where the correction component is deployed and the platform supports it, Native can restore approved settings and identify who changed them.

One Security Requirement, Different Platform Controls

A business rule such as “support agents may read tickets but never issue refunds” needs to be translated into the controls available on each platform. AWS, Google Cloud, Azure and OCI do not all offer the same tool-level authorization, so Native makes those differences visible instead of suggesting the same restriction is enforceable everywhere. The agent platforms add new policy types, shown in the table below. Agents also use cloud identities and resources, so the cloud-wide policies still apply: SCPs and RCPs on AWS, and their equivalents on Google Cloud, Azure and OCI.

AWSGoogle CloudAzureOCI
Agent platformAmazon Bedrock AgentCoreGemini Enterprise Agent PlatformMicrosoft Foundry Agent ServiceOCI Generative AI Agents
Tool gatewayAgentCore GatewayAgent Gateway, plus Apigee for MCPAPI Management AI gatewayTools are set on the agent
Tool-call rulesPolicy in AgentCore (Cedar)IAM deny, Principal Access Boundary, semantic governanceGuardrails at tool call and response, allowed-tools listsNot available on the platform
Agent identityWorkload identity and execution roleAgent IdentityMicrosoft Entra Agent IDResource principal
Cloud-wide policiesSCPs and RCPsOrganization policy constraints and IAM denyAzure PolicyIAM policies and security zones

Limit What a Manipulated Agent Can Reach

Prompt injection remains a risk, and content filters or prompt shields can help detect malicious instructions before an agent acts on them. When instructions get through, correctly configured infrastructure controls can still deny tool calls, narrow permissions and block unapproved destinations. For example, a gateway rule could stop an agent from requesting a $5,000 refund, but the same agent might still reach an internal refund API directly if its cloud role and network access allow it. That second route would never touch the gateway policy. Teams need to account for each route and apply the identity, network or application controls needed to close the gaps.

  1. Injection

    A web page, document or tool result carries instructions

    Content filters and prompt shields

    Not Native

  2. Tool misuse

    Issue a refund, delete a customer, run a new query

    Tool-call policy denies unapproved actions

    Denied

  3. Go around the gateway

    Call the runtime directly or impersonate a user

    Gateway routing and caller authorization

    Denied

  4. Credential theft

    Read the role’s credentials and use them elsewhere

    A scoped identity limits what the credential can access

    Limited

  5. Exfiltration

    Send memory or tool output somewhere unapproved

    Memory, output and network restrictions

    Denied

  6. Switch it off

    Flip the policy engine to log-only

    Organization policy limits changes; Native restores drift

    Restored

  7. Runaway

    Loop on a tool at machine speed

    Per-caller rate limits and a kill switch

    Limited
resource

Go Deeper: Architecture for Active Defense in the Cloud

This solution is one layer of a larger architecture. The ebook maps the whole thing: actors and zones, boundaries and baselines, and how perimeter, segmentation, and baseline controls compile into provider-native enforcement across AWS, Azure, Google Cloud, and OCI.

Get the ebook

Questions, Answered

It’s a policy that limits how an AI agent is configured, what it can access or which actions it can take, using controls in the cloud or agent platform. A boundary might require a private runtime, restrict the tools an agent can call or automatically expire its memory after 30 days.

The cloud and agent platform provide the actual enforcement points. Native helps apply one security requirement across the supported controls, reviews likely production impact and checks that approved settings stay in place. That means the policy can be managed as part of your broader cloud security architecture, with gaps shown explicitly when a provider lacks a needed control.

Most of the boundaries use controls enforced by the cloud or agent platform rather than a Native proxy. Tool-output screening is an exception: when configured, it attaches to the gateway request and response path, and teams can choose how failures are handled for individual tools.

Native shows what a proposed boundary would have blocked and who it would have affected. It replays audit logs and current state, the same way it does for every Native policy, and uses the platform’s own test mode where one exists: log-only on AWS, dry run on Google Cloud, audit mode on Azure and inform mode on OCI. The evidence varies by boundary and cloud, and your team reviews it before anything is enforced.

Yes. You can have Native add its rules alongside your existing policies or let it manage the engine for a particular gateway. Native-managed rules are tagged so you can identify and reverse them.

It depends on the work you want Native to perform. Read-only access supports discovery and available analysis. A scoped policy-management role is used for enforcement. An additional component deployed in your account can support faster correction and tool-output screening. You can choose the level that fits your rollout.

Costs depend on the platform, traffic volume and which logging or tracing you enable. Policy evaluation and simulation may have usage charges, while retained logs and traces can become a larger part of the bill.

Agent Boundaries is part of the Native platform.

Turn Security Intent Into Enforced Architecture

Book a demoExplore the platform