5
Credentials & reach:
Zero trust for agents
IMAGE PLACEHOLDER
Because they are in a constant state of motion, agents tend to generate a lot of noise. Most of that noise is harmless on its own and gets tuned out. However, an agent’s reach can turn noise into a governance problem. A destructive command in a temp folder is a cleanup action. However, a read of a credential file can potentially be a path to your cloud.
AI visibility:Relevant noise for security teams
The majority of agent users do things that trigger security-relevant detections. In fact, for this organization, 77% of people had at least one security-relevant detection in a single day. This means that either there was agent activity that matched a rule from a process the agent started that the kernel saw, or a tool the agent called that the agent-side hook saw. Across monitored sessions, 45% had one detection trigger, and 55% had none. Detections reach almost everyone but not every session.
During data collection, Sysdig AI Defense saw the detection rule for a destructive shell command fired 303 times in one day for 22% of agent users. 99% of these were rm -rf, so never “asked”, “caught,” or “blocked” in the sense of stopping anything. It was an ordinary cleanup made visible, not malicious. The rule recorded each command before it ran and did not stop any of them because Sysdig AI Defense was instructed to detect but not block. This frequency means agents routinely reach for destructive actions. Whether to stop them is a policy decision, which is what runtime control is about.
of users had a security-relevant detection in a single day
45% of sessions had one detection trigger 55% of sessions had no detection trigger The destructive-shell-command rule, in one day
While these detections are not always indicators of malicious activity, they shouldn’t just be written off as noise. Agents often do things that look like attacker activities because they do the same jobs: Read configs, fetch secrets, and delete files.
For this organization, a rule built for rare events was triggered for 22% of users. Security teams need high-fidelity detections, with context like specific paths, sessions, and modes.
Security is getting louder and busier, but in a good way. In addition to identifying malicious actions, security is highlighting gaps and risks in human user behavior that can be changed to reduce the threat of compromise. Organizations should baseline per user and session and alert on deviations in path, mode, and time.
Credentials:The agent is reading and borrowing yours
A credential file is not the same as a login. It’s a file on disk that stores secrets for convenience so that tools — or agents — don’t have to ask for them to complete tasks. A credential file has API keys, authorization tokens, session cookies, cloud service provider (CSP) access keys, and more, collected as if they were saved passwords in your browser. If copied, an attacker could act as a verified user across platforms like AWS, Docker, any registry, or GCP, without having to log in.
When an agent reads a credential file, which is a normal operating procedure, it doesn’t always log it. During data collection for this organization, agents’ own logs had no entry for reading credential files 82% of the time, but it was logged by the kernel every time.
The gap widens further when the agent binary itself reads the file. Those reads had no agent record 95% of the time. An agent binary is an executable, not a spawned child process, so the read isn’t hidden behind a child process or shell wrapper.
A read by the binary isn’t a tool call, so an agent’s tool-call log was never built to capture it. Both kinds of reads are poorly logged by the agent, but reads that run through a tool call, such as a shell command that opens a CSP credential file, are more likely to be logged.
When an agent read a credential file, 82% of the time the agent log had no record. The kernel had a record every time.
When the agent binary read a credential file, there was no agent log 95% of the time. The kernel had a record every time.
An agent’s log records the tool calls the model makes, but an agent binary read isn’t a tool call, so it rarely reaches the log. However, credential reads can be seen at the kernel level. An attacker who gains access to an agent through a malicious package, injected instruction, or poisoned MCP server inherits the agent’s reach, which could be widespread and detrimental. Secrets can be moved from large, long-lived files to short-lived credentials to reduce this risk.
Sysdig AI Defense notified this organization of a possible data-handling incident or data exfiltration. A customer support employee’s agent copied a file named “login emails” using the secure copy protocol (SCP) command to a host addressed only by an AWS IP during an analysis session. The same engineer had two prior, unrelated alerts in the same week. Sysdig AI Defense suggested asking the employee what was in the file, and who owns the destination host. If customer emails were present, it could have been a data-handling incident.
Zero trust for agents
An agent runs as the user who owns it. It inherits the user’s credentials, cloud sessions, and network, with no second factor and no separate identity. Zero trust, applied to agents, means treating them as separate, untrusted actors that happen to be using users’ identities. In that approach, what an agent can reach decides whether an alert is noise or a security finding. Ultimately, zero trust is how you limit reach before the alert fires.
Based on the data collected and the relationships identified by Sysdig AI Defense, organizations should consider the following identity management for their agents:
Give agents their own scoped, short-lived credentials instead of users’ long-lived files. Evaluate every call by what it touches, not by which session it’s in. Verify at the kernel, where agents can’t edit records or route around controls. Baseline per person and treat a pattern across alerts as the signal. One SCP is a command, but three alerts in a week is a pattern. 