Where Platform Teams Miss Agent Security

Service accounts give platform teams a sound model for automated workloads: known jobs, defined permissions, and visible changes. Agents expose its limits. They choose among available tools while working, so their real permission surface depends on what they can access, not only on the task you expected them to perform.

This is not a criticism of platform teams. The distinctions between agent security and service account security are subtle enough to miss until a concrete case makes them visible. This article examines those distinctions and where they become practical problems.

Mistake 1: treating agent permissions as fixed

A conventional service account performs a defined job with known operations. You grant the permissions required for that work, and the set stays stable until the job changes. Engineering decisions drive those changes, which appear in code review or deployment updates.

Autonomous agents work another way. While handling a task, an agent calls the tools available in its context. If it can use both a read API and a write API, and writing appears necessary, it will try to write. That is intended behavior, not an agent defect. For permission management, however, the effective surface is limited by what the agent has, rather than what you expected it to need.

So an agent's proper permissions cannot be determined from the task description alone. You must watch its behavior across many task instances. That differs from designing service account access, and skipping observation produces agents that are over-permissive because teams plan for the broadest case, or under-permissive because they guess at the smallest one.

Mistake 2: assuming network segmentation suffices

Network segmentation is a useful control for service-to-service traffic. When a process should not call a service, blocking that traffic at the network layer is dependable enforcement. Teams that have invested in segmentation often assume it covers agents too.

The gap is that agents can defeat the purpose of segmentation without crossing another network boundary. An agent with valid access to an internal API may use it to expose data it should not see or create side effects it was never meant to cause. The network permitted the connection; the failure sits at the application layer, in how the agent used it.

We commonly see agents with legitimate links to several services discover unexpected routes between them. Agent A may call a user data API to read records for enrichment and call a notification service to send system notices. Neither permission alone looks alarming. But if the agent combines user data into a notification and sends it to an unexpected destination, the pair creates a leakage route that network segmentation cannot block.

Mistake 3: trusting agent logs over infrastructure logs

Platform teams often make an agent's own logs the main audit source. That seems natural: the agent knows its actions and records them. Yet those logs come from the agent, so their accuracy and completeness depend on its logic and may be affected by prompt injection or hostile manipulation.

Infrastructure audit logs collected at an API gateway or authorization layer come from systems outside the agent runtime. The agent cannot control their records, and their format remains consistent across agents instead of reflecting each implementation. When the two sources conflict, infrastructure logs deserve more trust.

Agent logs are not worthless. They often contain richer meaning, including task context hidden from an API gateway. The error is treating them as sufficient for security. Build the activity trail mainly from infrastructure logs, then use agent logs for additional context.

Mistake 4: ignoring prompt injection risks

Prompt injection does not affect traditional service accounts in the same way. A service account runs code you wrote and does not interpret external content as instructions. Agents that handle documents, email, web pages, or API responses can be attacked when that content tries to replace their instructions.

For platform teams, this means an agent handling external content must be considered vulnerable to hostile input. Access that is acceptable for trusted internal data may be unsafe when the agent processes content from outside the trust boundary. An agent that summarizes documents and posts summaries to an internal channel should have write access limited to that channel, not to internal channels generally, because a malicious document could tell it to post elsewhere.

This is not saying you should restrict agents until they cannot do their jobs. It is saying that the permission scope for agents processing external input should reflect what could happen if that input were adversarial, not merely what you expect during normal operation.

Mistake 5: failing to define normal behavior

Service accounts tend to have predictable behavior. A nightly batch job reads about the same records, calls the same endpoints, and finishes in roughly the same window. Departures from that profile can be detected as anomalies.

Agents vary more because they adapt to each task, but that variation has limits. Over many runs, an agent classifying customer support tickets will establish patterns in API calls, records accessed, and operation timing. Large departures from those patterns matter even when no individual departure looks dangerous.

Teams that do not define and watch an agent's normal profile miss behavioral anomalies that would stand out in another automated system. Creating agent baselines is an operational practice that service account management does not need, since service accounts run code available for static inspection. Agents need behavioral monitoring that service accounts do not.

The correct mental model

Platform teams do not need to rebuild agent security from scratch. Much of the foundation from service account practice still applies: network controls, credential management, logging systems, and access reviews all remain valuable for agents.

The change is to add agent-specific reasoning: view permission surfaces as discovered dynamically rather than defined once, watch behavior alongside credentials, construct audit trails from infrastructure sources instead of agent self-report, and separate the threat model for agents handling external input from those handling only internal data. These additions cover the gaps where the service account model falls short.