The Problem: Why This Matters Now
Your developers are using AI coding assistants, connecting them to databases, APIs, and internal systems. They're loading third-party "skills" that execute code in their environments, and your traditional AppSec tools can't see any of it.
Snyk's analysis of nearly 10,000 developer environments found that 43% of developers run two or more AI coding environments simultaneously, and 50.8% have at least one MCP server installed. These tools operate before code reaches your repository, meaning they sit outside your existing security controls. The research identified 392 confirmed prompt injection vulnerabilities in tool descriptions alone.
This isn't theoretical. Your software supply chain now starts in the IDE, not in the commit. If you're still scanning only what hits your repo, you're missing the entire first stage of development.
What You Need Before Starting
Before you can secure what you can't see, you need inventory capabilities:
Access rights: You'll need read access to developer workstations or the ability to deploy endpoint agents. If you're running a BYOD policy, negotiate access to work-related directories at minimum.
Discovery tooling: Start with what you already have. Most EDR platforms (CrowdStrike, SentinelOne, Microsoft Defender) can inventory running processes and installed applications. You don't need specialized tools yet.
Asset management integration: Your CMDB or asset tracking system needs to accept custom attributes. You'll be tagging workstations with AI tool metadata.
Policy framework: Draft a working document that defines acceptable AI tools. Don't finalize it yet. You need data first.
Step-by-Step Implementation
Phase 1: Discovery (Week 1-2)
Deploy a discovery script to identify AI coding tools. Here's what you're looking for:
# Example: Identify common AI coding assistants
ps aux | grep -E 'copilot|cursor|codeium|tabnine'
# Check for MCP server installations
find ~ -name "*mcp*" -o -name "*model-context*"
# List VS Code extensions
code --list-extensions | grep -i 'ai\|copilot\|assistant'
Create a spreadsheet with columns: developer_id, tool_name, version, mcp_servers, last_updated. A shared spreadsheet gives you flexibility while you figure out what matters.
For each discovered tool, document:
- What systems it connects to (databases, APIs, cloud resources)
- What credentials it uses (API keys, tokens, OAuth)
- Whether it runs locally or calls external services
Phase 2: Risk Classification (Week 3)
Not all AI tools carry equal risk. Build a simple matrix:
High risk: Tools with MCP servers connecting to production systems, tools that execute code automatically, tools using company API keys
Medium risk: Tools that read code but don't execute, tools limited to localhost connections, tools using personal API keys
Low risk: Syntax completion tools, local-only models, read-only documentation assistants
Tag each discovered installation in your spreadsheet. This classification drives your governance decisions.
Phase 3: Credential Hygiene (Week 4)
The MCP server problem is fundamentally a credential problem. Those servers need authentication to connect to your systems. Audit those credentials:
# Find API keys in common config locations
grep -r "api_key\|token\|secret" ~/.config/
grep -r "api_key\|token\|secret" ~/.mcp/
For every credential you find:
- Verify it's in your secrets manager (1Password, HashiCorp Vault, AWS Secrets Manager)
- If not, rotate it and store it properly
- Configure the MCP server to pull from secrets manager instead of config files
- Set a 90-day rotation policy
This is tedious work. Budget 2-3 hours per developer if you're doing this manually. If you have more than 50 developers, write a script to automate credential discovery and flag violations.
Phase 4: Network Controls (Week 5-6)
MCP servers create new network paths. Your firewall rules probably don't account for IDE-to-database connections.
Update your network segmentation:
- Development workstations should connect to dev/staging only, never production
- MCP server traffic should route through your proxy for logging
- Block direct internet access from AI tools where possible
If you're using zero-trust networking (Cloudflare Access, Zscaler), create application policies for each MCP server type. Require device posture checks before allowing connections.
Phase 5: Skill and Extension Vetting (Ongoing)
Snyk found prompt injection vulnerabilities in tool descriptions. You need a review process for third-party skills before developers install them.
Create a request workflow:
- Developer submits skill name, source repository, and business justification
- Security reviews the source code for obvious issues (hardcoded credentials, network calls to unknown domains, code execution without sandboxing)
- Approve or deny within 2 business days
Don't make this a 3-week process. You're looking for egregious problems, not conducting a full audit. Budget 30 minutes per skill review.
Validation: How to Verify It Works
Run these checks monthly:
Inventory accuracy: Pick 10 random developers. SSH to their workstations and compare running AI tools against your spreadsheet. You should have 95%+ accuracy.
Credential compliance: Scan config directories for API keys. Zero findings = success. Any findings = your rotation process has gaps.
Network policy enforcement: Check your proxy logs. MCP server traffic should route through your logging infrastructure. If you see direct connections, your network controls aren't working.
Skill approval compliance: Audit installed extensions against your approved list. Anything not on the list is a policy violation.
Maintenance and Ongoing Tasks
Weekly: Review new AI tool installations from your EDR feed. Add them to your inventory.
Monthly: Run the validation checks above. Update your risk classifications as tools evolve.
Quarterly: Review and update your acceptable use policy. New AI tools launch constantly. Your policy should reflect current reality, not last year's threat model.
Annually: Audit your entire AI tool stack. Remove unused tools, consolidate where possible, renegotiate enterprise licenses.
The key insight: agentic development security is endpoint security, not application security. Treat AI coding tools like you treat browsers, email clients, and other endpoint software. They need inventory, configuration management, and policy enforcement. Your existing endpoint tools can handle most of this work. You don't need a specialized "AI security platform" yet. You need to use what you already have.
