Key facts
| Fleet growth | Enterprise agent fleets doubled in one quarter, as reported by Gravitee |
| Incident rate | 88% of organisations reported at least one agent security incident |
| Governance gap | Confidence in agents rose faster than the controls around them |
| Isolation | Ephemeral sandbox per agent run |
| Access | Least-privilege, scoped credentials per agent |
| Data path | In-region inference and log storage |
| Product status | Agents live; Playground in beta |
TL;DR
- Agent fleets doubled in a quarter; 88% of firms saw an incident, per Gravitee.
- Confidence grew faster than controls — that gap is the exposure.
- Every agent with credentials and tools is a new attack surface.
- Sandbox runs, remove standing keys, and scope permissions per task.
- Keep inference and logs in-region so a vendor incident is not your incident.
How it works, step by step
- Inventory agents and the credentials, tools and data each one can reach.
- Remove standing keys; issue short-lived, scoped credentials per run.
- Run agents in ephemeral sandboxes isolated from production networks.
- Require approvals for high-impact tools such as payments, deletes and external sends.
- Log tool calls and permission changes, and alert on anomalies in near real time.
- Review agent permissions on a schedule and revoke what the task no longer needs.
- Run an incident drill for a compromised agent rather than waiting for a real one.
Try it yourself
Open the API key security checklist →
The agent sprawl nobody secured
Agent adoption outpaced security review. Gravitee's State of AI Agent Security 2026 found enterprise agent fleets doubled in a single quarter and 88% of organisations had already experienced at least one agent security incident. The pattern is familiar from cloud and SaaS adoption: teams moved quickly because the tools were useful, and the controls arrived later. With agents, later is expensive because they hold credentials.
Confidence up, controls flat: the governance gap
The same research describes confidence in agents rising faster than the controls protecting them. Leaders believe the agents are safe; practitioners can point to shared API keys, broad permissions and no run isolation. That gap is where incidents live. Closing it does not require banning agents — it requires deciding, deliberately, what each agent may touch and proving it afterwards.
Why every agent is a new attack surface
An agent is an identity with tools. If it can read files, call APIs and send messages, then prompt injection, a poisoned tool result or a leaked key can turn it against you. Multiply that by dozens of agents across teams and you have dozens of identities to manage, each with its own blast radius. Traditional API security practices — scoping, rotation, monitoring — apply, but they must be applied per agent, not once for the platform.
Sandboxing, least privilege, and in-region data
Containment has three layers. Run agents in ephemeral sandboxes so a compromised run cannot persist. Give each agent a scoped identity with only the tools and data the current task needs. Keep inference and log storage in-region, under your jurisdiction, so a provider-side incident does not become your breach. Together these turn a compromised agent from a network event into a contained, reviewable run.
Security built in, not bolted on
Retrofitting security onto agent fleets is harder than starting with it. Plugsky agents run with scoped permissions, emit audit logs per run, and can be deployed in your VPC, on-prem or air-gapped. Security teams get a consistent control plane across agents instead of a spreadsheet of exceptions. Check the docs for the current capability matrix before you design your rollout.
Honest comparison
| Control | Plugsky agent stack | Typical agent deployment | No governance |
|---|---|---|---|
| Run isolation | Ephemeral sandbox per run | Shared runtime | None |
| Credentials | Short-lived, scoped per run | Shared API keys | Personal keys |
| Permissions | Least privilege per agent | Broad and long-lived | Unreviewed |
| Monitoring | Tool-call logs and alerts | Partial | None |
| Data path | In-region options | Provider-dependent | Unknown |
| Deployment | VPC, on-prem, air-gapped | SaaS only | Shadow usage |
Frequently asked questions
What do the 88% and fleet-doubling figures mean?
They come from Gravitee's State of AI Agent Security 2026, which reported that enterprise agent fleets doubled in a quarter and 88% of organisations had at least one agent security incident. Use them as directional signals about control gaps.
Is prompt injection a real risk for agents?
Yes. An agent that reads untrusted content and calls tools can be steered by injected instructions. Isolation and least privilege limit what a successful injection can reach.
How are agent credentials different from API keys?
They should be far more restricted: short-lived, scoped to specific tools and data, and tied to one task. Long-lived shared keys turn a single compromise into platform-wide access.
Do sandboxes break tool integrations?
Not if the sandbox is provisioned with the network routes and credentials the task needs. Design each agent's allowed connections explicitly rather than granting broad access.
Where should agent logs live?
In your chosen jurisdiction, with retention that matches your obligations. In-region logs keep forensic evidence under your control after an incident.
Can this run air-gapped?
Yes. Enterprise deployment options include VPC, on-prem and air-gapped environments for teams that cannot send data to a public cloud.
How do we start without a big program?
Begin with the highest-privilege agents: cut standing keys, scope tools, add logging, then expand. The free plan and 14-day full-access trial let you evaluate the platform first.
Plugsky (2026). “88% Had an AI Agent Security Incident — Fix”. Plugsky. Available at: https://plugsky.com/news/ai-agent-security-sandbox (last updated 2026-09-25).