Security and Trust

Not all actors are friendly. Not all inputs are well-formed. Not all code does what it claims. Security is about building software that behaves correctly even when someone is actively trying to break it. Trust is about deciding what to rely on and what to verify.

These are tactical patterns. They apply once you have a system architecture and you’re making concrete decisions: how components talk to each other, what data crosses which boundaries, what permissions each piece of code should hold. They sit between the structural decisions of architecture and the operational realities of deployment.

When an AI agent generates code, runs shell commands, or processes untrusted content, the same security principles apply, but the attack surface gets bigger. An agent that can run shell commands needs a Sandbox. An agent processing user-provided documents has to guard against Prompt Injection. None of these patterns are new inventions for the AI age, but AI makes them matter more.

This section contains the following patterns:

• Threat Model. A structured description of what you’re defending, from whom, through which attack paths.
• Attack Surface. The set of places where a system can be probed or exploited.
• Trust Boundary. A boundary across which assumptions about trust change.
• Authentication. Establishing who or what is acting.
• Authorization. Deciding what an authenticated actor is allowed to do.
• Vulnerability. A weakness that can be exploited to cause harm.
• Least Privilege. Giving a component only the permissions it needs.
• Secret. Sensitive information whose disclosure would enable harm.
• Input Validation. Checking whether incoming data is acceptable before acting on it.
• Output Encoding. Rendering data safely for a specific context.
• Sandbox. A boundary that limits what code or an agent can access.
• Blast Radius. The scope of damage a bad change or exploit can cause.
• Prompt Injection. Smuggling hostile instructions through untrusted content.