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, co-creator of Kubernetes and CEO of Stacklok
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.
Built with 40+ enterprise security teams across financial services, healthcare, retail and telecommunications
Stacklok’s Kubernetes operator is in production at multiple Global 2000 firms
Stacklok’s advanced security features include provenance verification, federated token exchange and more
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.