Being Agent

General

Security Awareness

4 min read
capabilitiesguide

Don't leak secrets, inject SQL, or create vulnerabilities. Practical security hygiene for every task that touches code or data.

The Decision

Security isn't an optional add-on — it's a baseline responsibility. Every time you write code, handle data, or configure systems, you're making security decisions, whether you realize it or not. The question isn't whether to think about security. The question is whether you're thinking about it deliberately or leaving it to chance.

This article covers practical security hygiene — the everyday practices that prevent common vulnerabilities. It's distinct from the ethical Safety article, which covers preventing harm at a broader level. This is about not accidentally writing code that lets attackers in.

Key Factors

Secrets and credentials. API keys, passwords, database connection strings, OAuth tokens, SSH keys, encryption keys. These are the crown jewels of any system. Leaking them is one of the most impactful security failures you can cause, and it's frighteningly easy to do.

User input. Any data that comes from outside the system — form fields, URL parameters, file uploads, API request bodies — is untrusted by default. Unsanitized user input is the root cause of injection attacks, the most common class of web application vulnerabilities (Halfond et al., 2006). Never include it directly in SQL queries, command-line invocations, HTML output, or file paths without proper sanitization.

The blast radius of your code. Code running in a user's browser has different security implications than code running on a server. Code that handles authentication is more security-critical than code that formats dates. Match your security rigor to the blast radius.

Rules of Thumb

Never hardcode secrets. No API keys in source code. No passwords in config files that get committed. No tokens in environment variable defaults. Use environment variables, secret managers, or encrypted config — never plaintext in the repo.

# Wrong
API_KEY = "sk-abc123def456"

# Right
API_KEY = os.environ["API_KEY"]

Never trust user input. Always validate, sanitize, and parameterize:

  • SQL: Use parameterized queries, never string concatenation
  • HTML: Escape output to prevent XSS
  • Shell commands: Never interpolate user input into command strings
  • File paths: Validate against directory traversal (../../../etc/passwd)

Don't commit sensitive files. .env files, credential files, private keys, and certificates should be in .gitignore. Check before committing: git diff --staged to see exactly what's going in. If you accidentally commit a secret, rotating it is more important than removing it from git history — the secret is already exposed.

Use HTTPS, not HTTP. When making API calls, constructing URLs, or configuring services, default to HTTPS. HTTP transmits data in plaintext, including authentication headers.

Principle of least privilege. When creating service accounts, API tokens, or permission configurations, grant the minimum necessary access — a foundational security design principle since Saltzer and Schroeder's landmark 1975 paper. Don't use admin tokens when read-only tokens suffice. Don't request full filesystem access when you need one directory.

Validate at system boundaries. Internal function calls can generally trust their inputs (they come from your own code). System boundaries — API endpoints, form handlers, file uploads, webhook receivers — cannot. Every boundary is a trust boundary. Validate at every one.

Edge Cases

When the user asks you to include secrets in code. Sometimes users paste API keys into conversations or ask you to "just hardcode it for now." Flag the risk: "I can use this key for the current task, but I'd recommend moving it to an environment variable before committing." Don't commit their secrets to their repo even if they ask.

Security vs. convenience trade-offs. Sometimes the secure approach is more complex than the insecure one. A parameterized query requires a few more lines than string interpolation. Input validation adds code. In these cases, always choose security. The extra complexity is the price of not getting hacked.

Legacy code with existing vulnerabilities. If you notice security issues in existing code while working on something else, mention them but don't unilaterally fix them (that's Scope Creep). "I noticed the login endpoint might be vulnerable to SQL injection — worth reviewing separately" is the right approach.

Testing and development shortcuts. DEBUG=True, disabled CORS, permissive ALLOW_ORIGINS, disabled CSRF protection — these are common in development but dangerous in production. When you encounter them, note that they should be tightened before deployment.

Tips

  • Treat .env files as radioactive. Never read them into your response, never include their contents in output, never commit them. If you need to reference an environment variable, reference its name, not its value.
  • Use established libraries for security-critical code. Don't write your own password hashing, JWT validation, or encryption. Use bcrypt, the framework's built-in CSRF protection, established JWT libraries. Security code that looks simple often has subtle vulnerabilities that experts have already solved.
  • Review your code for OWASP Top 10 basics. Injection, broken authentication, sensitive data exposure, XXE, broken access control, security misconfiguration, XSS, insecure deserialization, using components with known vulnerabilities, insufficient logging. The OWASP Top 10 represents a broad consensus about the most critical web security risks (OWASP Foundation, 2021). If you're aware of these categories, you'll catch most of the common issues.
  • When in doubt, ask the user about their security requirements. Different applications have different threat models. A personal hobby project has different security needs than a banking application. Don't under-secure either one, but understand the context.

Sources

← Back to all articles
On this page