Last week, I was talking with the VP of Site Reliability and Security at a fintech company building an agentic AI platform for asset managers.

His new CPO had made a seemingly simple request: give me an AI agent with cloud access so I can prototype applications by chatting with it.

Describe the tool, and the agent builds it. No waiting on DevOps for every change.

Great for speed. Much harder for security.

The agent's value comes from its autonomy. But that autonomy requires cloud permissions and network access that can change with every prototype.

‍

If the VP says no, security becomes the bottleneck. If he says yes, how does he keep an autonomous agent under control?

‍

Nobody knew exactly what permissions to give the agent

The VP told me plainly: he didn't know what permissions to grant it.

And that's the problem with a request like “build me a prototype.” Depending on the application, the agent may need to:

• Deploy a container or Lambda
• Read from or write to S3
• Provision cloud resources or networking
• Create or configure IAM roles

That last one is particularly sensitive. If an agent can create roles and control the permissions attached to them, its effective access can extend beyond its original grant.

Of course, you should apply least privilege and scope the agent's permissions as tightly as possible.

But when nobody can fully predict what the next prototype will require, the temptation is to grant broadly now and scope down later and “later” has a habit of becoming permanent….

‍

1. Scoping permissions is not enough. You need to baseline how the identity behaves

Imagine the agent is allowed to both s3:GetObject and s3:DeleteObject.

For weeks, it only reads objects. Then one day, it starts deleting them.

The action is within the agent's granted permissions. But it is outside its established behavior.

Least privilege answers an important question: What is this agent allowed to do? A behavioral baseline answers a different one: Is what this agent is doing normal and expected ?

‍That's why, alongside least privilege, I would continuously baseline each IAM role, service account, or access key across:

• Actions: What API operations does this identity normally perform?
• Resources: Which resources does it normally access and what type of operations does it usually perform on those resources?
• Origin: From which workload, network, region, or geography is the identity normally used?
• Activity: When is it normally active, and does the activity happen only within account or cross account ?

‍

‍2. Give each agent its own identity

There is one prerequisite for making this baseline more meaningful: A distinct IAM role per agent. If several agents share one identity, their activity is mixed into the same history.

A distinct identity gives you something you can attribute, baseline, monitor, and investigate for each agent.

‍

3.Constrain the agent’s network reach, then baseline what remains

The same principle applies to the network.

Start by isolating the agent as much as the use case allows. A sandbox account, an “isolated” VPC, and tightly scoped security group Inbound and Outbound rules

But the CPO's agent still needs to build useful prototypes. That may require access to:

• Preproduction data
• Internal applications or services
• External APIs
• ....

So some network paths have to remain open.

A security group may allow outbound HTTPS to the internet. That doesn't tell you whether the agent's workload is communicating with the same five domains it normally uses or a domain it has never contacted before.

This is where network behavioral baselining becomes important.

For the agent workload, baseline and monitor:

• Contacted Destinations and Domain Names: Which domains and geographies does it normally reach? A first-time destination is a clear behavioral change.‍
• Ports and protocols: Which ports and protocols does it normally use? A workload that normally communicates over HTTP/HTTPS and suddenly initiates SSH is a meaningful change.
• Outbound data volume: How much data does it normally send? A significant deviation from its usual egress volume deserves attention.
• Internal communications: Which internal workloads and databases does it normally talk to, across VPCs and accounts. A new workload-to-workload Inbound or outbound communication is worth surfacing - especially for sensitive assets like databases.

‍

‍4. Correlate identity and network behavior

For AI agents, the strongest signal often isn't one behavior change. It's multiple changes occurring together across identity and network activity.

• Identity + network give you the full behavioral picture: Identity shows what the agent did:  the API calls, resources accessed, and permissions exercised. Network shows what communicated as a result:  internal contacted workloads , external destinations, ports, and data movement. Bringing both together not only strengthens the signal when behavior changes across both planes, it also gives security the context in one place instead of spending investigation time stitching together IAM events, flow logs, DNS logs, and cloud configuration data.

‍

The answer was never yes or no

Back to the VP of Site Reliability and Security from the start of this article. His product team wanted an AI agent with enough cloud access to let the new CPO prototype by chatting with it, without waiting on DevOps for every change.

The real question was never simply whether to grant the agent cloud access. It was how to enable that autonomy without losing control as the agent's behavior evolves.

‍

Because with an AI agent, new behavior is not necessarily bad behavior. It is expected.

Today it may read from S3 and deploy a Lambda. Tomorrow, because the CPO asks it to build something different, it may access a new service, interact with a new resource, or connect to a new external API.

‍

Trying to predefine every legitimate action, resource, destination, and network path defeats part of the reason for giving the agent autonomy in the first place.

So the answer isn't “no,” and it isn't an unqualified “yes.” It is yes, with guardrails and continuous behavioral monitoring:

• Give each agent its own identity so its actions can be attributed and baselined.
• Scope permissions and network reach as tightly as possible.
• Baseline identity and network behavior to establish how the agent normally operates within those boundaries.
• Surface behavioral changes even when the underlying action or connection is allowed.
• Correlate identity and network changes to understand the broader context around a deviation.
• Continuously revalidate access against what the agent actually uses as its tools and responsibilities evolve.

‍

You may not define the perfect policy on day one. But you can define the boundaries, understand what happens inside them, and know when the agent's behavior changes.

‍

How CloudFence provides behavioral monitoring & visibility across both layers

‍

This is the model we are building at CloudFence: correlate identity behavior with network behavior to understand not only what a workload or agent is allowed to do, but what it actually does and when that changes.

CloudFence is fully agentless and builds behavioral baselines from native cloud telemetry, including AWS CloudTrail, Azure Monitor logs, VPC Flow Logs, VNET flow logs, and DNS logs, without requiring agents on the workloads or virtual appliances to be deployed inside your cloud

From hundreds of GB of logs to an understandable behavioral baseline

Cloud environments generate enormous volumes of CloudTrail events, VPC Flow Logs, and DNS logs. Those logs are invaluable, but they are often stored in a SIEM and queried when an investigation has already started.

CloudFence uses that telemetry differently. We continuously condense it into a compact, graphical behavioral baseline that shows how each identity and workload normally behaves.

When behavior changes, CloudFence keeps the different versions of that baseline so teams can quickly see:

• What changed: a new action, resource, destination, port, or geography.
• When it changed: when the new behavior first appeared
• What the previous baseline looked like: so the change has immediate context
• What risk comes with the change: based on the identity, resource, network path, and behavior involved

Instead of searching through hundreds of gigabytes of raw telemetry to reconstruct what changed, security teams get a continuously maintained picture of normal behavior  and a history of how that behavior evolves.

‍

Identity behavior 

For each identity, CloudFence establishes its observed behavior and surfaces changes such as:

• New Action type: New API actions or permissions exercised
• New Resource type: First-time access to resources 
• New Origin : Changes in where an identity is being used from
• New Activity pattern: Previously dormant identities becoming active

‍

Network behavior

For each workload, CloudFence learns its normal communication patterns and surfaces changes including:

• First-seen domains and external destinations
• New countries, organizations, ports, or protocols
• New workload-to-workload, VPC, or account relationships
• Changes in outbound traffic volume

‍

Bringing both together

The goal is to give security teams one behavioral view across identity and network: what changed, which identity and workload were involved, what resources were accessed, where communications went, and how those changes relate.

‍

‍

‍

‍

‍