The one-hour baseline
Start here if you have a working prototype and nobody owns security. You do not need to redesign the product to check where its keys live, who can call its model endpoint, or what permissions your coding agent has. Work through these controls before adding another integration.
Keep model API keys on the server. Put a budget around calls and bound the work one request can trigger. Read your system prompt as if someone outside the team could see it. Then inspect the configuration files, hooks, skills and MCP servers that your coding agent reads or runs.
Done means you have checked the built client for keys, exercised the request limits, and read the files that grant your agent access. A setting in a dashboard or a sentence in a prompt is not evidence by itself. Keep the result of each check with the code so the next person can repeat it.
Know the limit
This baseline does not test retrieval isolation, tool authorization or actions that need approval. It gives you a starting point. Continue to the next stage before real users depend on the feature.
Controls in this stage
Lock down your coding agent's config files
Coding-agent config has no permission bypass, secrets or unreviewed hooks, and MCP versions and filesystem access are restricted.
Keep model API keys off the client
Model API keys live only on the server, use separate environments and never appear in the built client or repository.
Assume your system prompt will leak
System prompts contain no keys, internal URLs or credentials, and security rules are enforced in code.
Cap spend and rate-limit every AI endpoint
AI endpoints require authentication, limit each user and IP, and cap input, output, agent iterations and tool calls.
Vet skills, plugins and MCP servers before you install them
Skills, plugins and MCP servers have reviewed source, pinned versions and narrow permissions, with hidden instruction text checked.