The 15 Principles of Secure Agentic Systems
“The biggest challenge for enterprises is that no matter how sophisticated an agent is, it will never be accountable”.
~ Craig McLuckie, Stacklok CEO and Founder
The 15 Principles of Secure Agentic Systems
We worked with more than 40+ enterprises to define the 15 principles of secure agentic workflows.
Principles in the guide include:
- Explicit identity. Every agent needs its own identity, not a copy of its user’s credentials
- Scoped authorization. Agents should only have access to what they need, enforced at the infrastructure layer
- Lifecycle management. Agent governance must be maintained, and every agent needs an off switch.
That’s just a peek; there are more details inside. If you need to rally your team around a shared definition of what matters, this guide is a strong starting point.
We’re proving Kubernetes is an ideal control plane for MCP servers now and AI agents next:
Our users make 4M tool calls every month (doubling every month)
Our Kubernetes operator is in production at multiple Global 2000 firms
Our open source platform, ToolHive has external maintainers and a growing community of contributors
Frequently asked questions
The highest-impact risks are credential mismanagement (agents running on shared or user-level credentials), unconstrained tool access (agents with more permissions than their task requires), and absent runtime isolation (code execution without a sandbox boundary). These risks compound at scale: what’s a contained incident with one agent becomes a systemic exposure with hundreds.
Explicit identity means every agent has its own uniquely issued, scoped credential — not a copy of its user’s credentials or a shared service account. It matters because when an agent’s credential is compromised, you need to isolate and revoke it without affecting every other system that credential touches. OAuth 2.0 and SPIFFE are the emerging standards for this.
Least-privilege for agents cannot be enforced through system prompt instructions alone — a sufficiently adversarial input can override behavioral guardrails. Scoped authorization must be implemented at the infrastructure layer: through scoped API keys, role-based tool inventories, and access controls the agent cannot reason its way around. The MCP layer is where this enforcement should live.
Each MCP server is third-party code running inside your environment with access to your agent’s context and credentials. Container isolation ensures that if one MCP server is compromised — through a supply chain attack or a poisoned tool — the blast radius is contained to that server’s execution environment and does not propagate to adjacent systems or agent state.
Here are some examples: Stacklok runs every MCP server in an isolated container by default, implementing a runtime boundary. Stacklok’s enterprise platform adds per-request identity via OIDC/OAuth and Okta/Entra ID integration, supply chain provenance attestation, immutable audit logging via OpenTelemetry, and a curated registry with admin-controlled tool governance.