A First Look: Under the Hood of AI Agents
With early access to Sysdig AI Defense, one software development company spent a month looking at AI agent usage across their enterprise. Below is what they found.
Citizen developers are generating code
At this organization, 50% of the employees using AI agents work outside of the engineering department. Marketing, human resources, sales, legal, and finance all used AI agents daily, and they aren’t just chatting with them. Among the non-engineers using agents, an average of 42% of them had an agent run code, a build, a package install, or a cloud or cluster command.
A finance employee building tools likely doesn’t possess the same security knowledge as an engineer, nor are they likely to have the same reviews in place by default. But that shouldn’t stop them from creating. Organizations should watch installs and CLI calls and provide an approved, sandboxed path for them to build.
Tool calls are running without human approval
People turn off prompts to keep their work moving, and although it isn’t generally a sign of carelessness, it can open organizations up to greater risk. More than 60% of this organization’s tool calls ran without a human approving them — 52% screened by Claude Code’s auto-mode classifier instead of a person, and 9% with permission prompts intentionally turned off (YOLO mode).
But the answer to minimizing this risk isn’t blocking everything or turning a blind eye. Organizations need to understand their risk profiles at different levels, and allow tools, agents, and extensions based on what they can reach and change.
The agent’s account of its own actions isn’t enough
For every tool call this organization’s agents logged, the kernel captured seven processes. While an agent’s log may help a user debug a session, it’s not meant to be used as audit evidence because the agent writes it. The kernel sees what actually ran at the process level, regardless of the tool or API used. However, additional data shows that the security team needs both to see the full picture. For example, when an agent read a credential file, the agent’s log had no entry 82% of the time. However, the kernel logged every read.
Connecting unverified extensions to agents
Nearly half (47%) of the MCP servers in use came from third-party registries or vendors for this organization. Each server is a trusted relationship that only takes one line of config to connect to an agent, and once connected, it has access. Servers can also update silently in the background, so the one you trusted last week may not be the one running today.
Matching models to tasks
More than 50% of the organization’s AI spend went to duplicative processes and capabilities. With visibility into which models are used, scoped to the team and user behind each agent, organizations can tie model choice to the task and cut duplication.
What else is in the full report
This is only a fraction of what one month of agent activity uncovered. Dig deeper to discover:
- How often security-relevant detections are triggered.
- A risk-tier framework for allowing agents and extensions by what they can reach
- Real alerts from the deployment, including a possible data exfiltration, an unapproved model provider, and a change to cloud permissions.
- What model tiers employees are actually using day to day.
- A risk reduction table you can hand to your team.
Odds are, AI agents are already running in your organization. The question is whether you know where they’re running, and whether you can see what they’re doing. Read the full report to see what this organization found and how you can start closing the gap.
