TL;DR: Apply CISA Secure by Design to AI agents: make safe configurations the out-of-the-box default, so teams ship agents that are secure before anyone touches

When a team ships an AI agent, the first moment it runs it may already have access to APIs, data stores, and decision paths. A misconfiguration at that instant is not a software defect to be patched later; it is a live hazard. That is why the Secure by Design principles laid out by the United States Cybersecurity and Infrastructure Security Agency (CISA) carry immediate weight for agent builders. With over 200 software manufacturers already signed on to the Secure by Design pledge, the industry is moving toward a model where security is a producer responsibility, not a consumer chore. For small and mid-sized engineering teams in Europe, this shift reframes how agents must be built: the safe configuration must ship first.

Understanding Secure by Design

CISA’s Secure by Design initiative, detailed at https://www.cisa.gov/securebydesign, contends that technology providers must take ownership of customer security outcomes. The central idea is that products should be designed and built to be secure out of the box, rather than leaving users to configure safety after the fact. As CISA Senior Technical Advisors Bob Lord and Jack Cable have explained, this means treating security as a core business requirement during the design phase, not just a feature checklist. The initiative asks manufacturers to embrace radical transparency, ship with security features like multi-factor authentication (MFA) and logging enabled at no extra cost, and lead from the executive level so that security is a business priority.

For AI agents, this concept becomes even more pressing. An agent is not a passive tool; it acts on behalf of a user or system, often with access to sensitive resources. If the default configuration grants broad permissions, lacks logging, or suppresses safety checks, the agent becomes an immediate risk the moment it is deployed. Secure by Design translates directly into safe defaults for agent behavior.

Why Safe Defaults Are Critical for AI Agents

Traditional software can often be secured after installation by an experienced administrator. But AI agents, especially those designed for non-expert users, begin interacting with the environment immediately. An agent with unrestricted tool access could delete files, send unauthorized emails, or leak data if its initial state is permissive.

CISA's guidance underscores that the builder, not the user, should carry the burden of security. For agent teams, that means:

  • Out-of-the-box, the agent operates with least privilege. It should only have the minimum permissions necessary to perform its core function, with any escalation requiring explicit, informed user action.
  • Guardrails are enabled by default. Content filters, output validators, and action limits must be active from the first run. The user should have to deliberately disable them, not actively enable them.
  • Logging and monitoring are on from the start. Every action the agent takes should be recorded, and critical events should generate alerts, all without extra configuration.

These defaults embody the Secure by Design principle: the product is secure before anyone touches the settings.

Shifting the Security Burden to Builders

Secure by Design offers a framework that can actually reduce long-term costs by preventing incidents. When a team ships an agent with safe defaults, it avoids the spiral of user misconfiguration, support tickets, and potential breaches.

The core shift is to internalize security as a design constraint, not an aftermarket add-on. During the design phase of an agent’s lifecycle, teams should:

  1. Define minimal tool permissions. Map every capability the agent needs and assign the lowest required access. If the agent only needs to read data, do not grant write access in the default profile.
  2. Build safety scaffolding. Incorporate guardrails directly into the agent’s decision loop. For example, require human confirmation for high-risk actions, cap financial transactions, or limit the number of external calls per session.
  3. Design for transparency. Ensure logs are comprehensive and surfaced to the user or administrator in a usable format. This aligns with CISA’s call for security-relevant logging being available without extra effort.

This approach does not eliminate the need for configuration; it simply means that any deviation from the safe baseline is a conscious and marked choice by the user, not a trap hidden in settings.

Three Principles for Agent Teams to Apply Now

Drawing directly from CISA’s Secure by Design joint guidance, agent teams can adopt three operational principles immediately:

1. Least privilege as the initial state. The agent’s default configuration should grant the narrowest set of permissions. If the agent is a customer support bot, it should be able to search knowledge bases but not delete tickets unless explicitly authorized and confirmed.

2. Conservative tool access. Tools the agent can invoke should be limited to those essential for its defined tasks. Any tool that could cause harm, such as sending external communications or modifying critical data, must ship in a disabled state and require a deliberate activation step.

3. Guardrails that ship enabled. Safety features like output validation, content filtering, and rate limiting must be active out of the box. The user should have to explicitly turn them off, not hunt through settings to turn them on.

These principles mirror the Secure by Design pledge’s call for measurable, specific actions. Over 200 manufacturers have already committed to such practices for traditional software; agent teams can do the same.

From Feature to Business Priority

For small and mid-sized tech companies, adopting secure-by-default development is not just about compliance; it is a competitive advantage. Customers are increasingly aware of AI risks, and a reputation for shipping safe, trustworthy agents can differentiate a product in a crowded market. Moreover, European regulators are moving toward stricter rules for AI systems, making built-in security a future-proofing strategy.

CISA’s Secure by Design campaign emphasizes that security must be driven from the top. Engineering leaders should champion safe defaults as a non-negotiable part of the product definition. When the CEO and CTO prioritize security outcomes, the team treats it as foundational rather than a feature request from a customer.

The result is agents that are not only more secure but also more reliable and easier to support. A safe default configuration reduces the attack surface while giving users transparency and control.

Frequently Asked Questions

Q: How does Secure by Design differ from traditional security approaches for software?

A: Traditional security often relies on users to configure protections correctly. Secure by Design shifts the responsibility to the makers, requiring that products be secure out of the box. For AI agents, this means the default state is the most conservative one.

Q: Can safe defaults make an agent less useful?

A: Safe defaults should not cripple an agent. They should match the core use case with minimal permissions. Users can expand capabilities as needed, but the baseline ensures they do not inadvertently expose themselves to risk.

Q: What role do tools and APIs play in secure agent design?

A: Tools and APIs are the agents' action interfaces. By enforcing least privilege at the tool level and requiring explicit activation for high-risk operations, teams can prevent unintended actions.

Q: How do we balance security with the need for rapid prototyping?

A: Secure by Design principles can be integrated into agile workflows. Prototyping can use constrained sandboxes or simulated environments. The key is to design the safe defaults early, so they are part of the architecture, not a last-minute patch.

Further Reading