AI agent security: a lifecycle, not a simple control

For years, enterprise security has operated on a fairly linear logic: an identity is established, whoever requests access is authenticated, what they can see is decided, and those permissions are enforced. AI agents break that scheme. They don't just query systems: they interpret goals, choose tools, create subagents, make decisions, and execute actions, often with credentials and permissions inherited from people. The problem is not that the agent lacks credentials, but that those credentials can authorize actions the human never intended to delegate. And, unlike classic software, an agent can change its execution path on the fly to fulfill its goal.

That forces a change of approach: security can no longer ask only who is acting, but what the agent is trying to do, with whose authority, and under what policy. And that is not solved with an isolated checkpoint. A continuous security lifecycle for agents is needed.

The example that explains everything

Imagine an agent trying to delete a production database using a developer's legitimate credentials. Network controls see authorized traffic. The runtime sees an approved process. The identity provider confirms the credentials are valid. All three layers work as designed. The missing question is whether that specific agent should be able to execute that specific action, even though the human whose credentials it inherited could legally do so.

The answer requires identity and authorization context at the point of action. In practice, an authorization decision should consider the agent's identity, the person or service that delegated authority to it, the requested operation, the target resource, and the applicable policy. And it must be applied before the operation executes. The agent harness—the layer that connects the model to tools, APIs, files, and external systems—is a key place to enforce that control, along with other trust points such as tool services and the resource APIs themselves. It's not about replacing existing defenses, but about integrating authorization into agent execution.

Four disciplines, one continuous cycle

A practical security architecture for agents rests on four interconnected disciplines: observe, enforce, build, and deploy. They are not sequential phases that each organization must complete in order, but a continuous cycle that can be entered at the point that best fits existing infrastructure and maturity. A company with agents already in production can start by observing their behavior. A team developing a new agent can start by incorporating authorization into its architecture from design. And an organization expanding a deployment can discover new activity that forces a review of its policies.

Observe: know what they actually do

Many companies already have some inventory of applications and are beginning to extend it to AI agents. It's a useful starting point, but knowing an agent exists is not the same as understanding what it does. Security teams need visibility into the actions agents actually attempt: what tools and APIs they invoke, what commands they execute, what systems and sensitive resources they access, what credentials and delegated permissions they use, what subagents they create and what authority they inherit, and what actions would violate a proposed policy. Architecture diagrams or configuration files do not answer that reliably. The important evidence is in execution.

That's why agent observability must go beyond conventional logs and application monitoring. Observed actions must be connected with identity, delegation, and authorization context. Furthermore, observation should allow evaluating potential policies without immediately interrupting production activity. It already happened with intrusion prevention systems and web application firewalls: enabling aggressive blocking rules all at once disrupted legitimate applications. First you monitor, establish behavioral baselines, and then enforce policies progressively. The same happens with agents, even though their behavior is much more dynamic. You cannot govern with judgment what you have not observed.

Enforce: deterministic limits on probabilistic behavior

Once behavior is understood, it's time to define and enforce limits. Here the distinction between the probabilistic—the model—and the deterministic—the authorization rules—appears. Agent security is a defense-in-depth problem: the network controls how they communicate, endpoint and runtime protections limit where and how code executes, infrastructure and silicon protections provide a trusted execution base, and model guardrails help shape behavior. All those layers complement each other, but none alone answers the question of whether this agent, with this delegated authority, should execute this operation on this resource.

What it means for an SMB and what we recommend

For an SMB, the temptation is to think all this is for large corporations. It is not. Any company that connects an agent to its CRM, ERP, email, or shared files is creating an actor with inherited credentials and the ability to execute actions. And often that agent is deployed with the token of an employee with broad privileges because it's the fastest way.

Our concrete recommendations:

• Inventory and observe before blocking. Make a real list of agents in use, even if informal, and record what tools and data they touch. Without that picture, any policy will be blind.
• Apply least privilege to agents too. Do not reuse human credentials with broad permissions. Create dedicated identities for agents, with permissions scoped to the operation they must perform.
• Define policies by action, not just by identity. Ask yourself what specific operations (delete, send, modify, export) each agent can execute and on what resources.
• Start in observation mode. Evaluate policies in shadow mode before blocking, as was done with WAFs. That way you avoid breaking legitimate processes.
• Review the cycle with every change. A new agent, a new tool, or an expanded permission forces you to observe and adjust again. The cycle never ends.

This approach fits with what we have been advocating on other fronts: security is not a product you install, but a discipline you maintain. We saw it with AI pentesting, where the harness matters more than the model, and we see it again here: the deterministic control around the agent weighs as much or more than the model itself. It's also worth keeping in mind that agents expand the credential exposure surface, a risk we already addressed when discussing the leak of customer secrets at Railway.

The conclusion is simple: an agent is not protected with a door, but with a process. Observe, enforce, build, and deploy in a loop. For an SMB, starting by observing and scoping permissions is cheap and immediately reduces risk. The expensive part is discovering, after it has already happened, that the agent did exactly what its credentials allowed.

Source: The New Stack. Analysis and adaptation: ForgeNEX.