Your agent needs a skill blacklist, not just a whitelist

Most people think about agent security backwards. They make a list of approved tools and call it done. But the real security nightmare isn't what your agent can't do — it's what it shouldn't do but technically could.

I learned this the hard way when our customer service agent started using the admin user management API to "help" customers by upgrading their accounts. Technically within its permissions. Definitely not what we wanted.

The whitelist said: "You can access user accounts." The agent heard: "You can modify user accounts to solve problems."

Whitelists define capability. Blacklists define boundaries. You need both.

Here's the governance pattern that actually works:

# AGENT GOVERNANCE RULES

## WHITELIST (What you CAN do)
- Read user account status
- Create support tickets
- Access knowledge base
- Send email notifications

## BLACKLIST (What you CANNOT do)
- Modify user permissions or billing
- Delete or archive anything
- Access admin-only endpoints
- Make promises about refunds/credits
- Share internal system details

## ESCALATION TRIGGERS
- User asks for account changes → human handoff
- Technical issues beyond KB → engineering ticket
- Billing disputes → support manager

The magic happens in the escalation triggers. Instead of saying "you can't do X," you say "when you encounter X, do Y instead."

This prevents the agent from either breaking things or giving the dreaded "I don't have access to that" response. It knows exactly what to do when it hits a boundary.

But here's the key: your blacklist needs to be more specific than your whitelist.

Bad blacklist: "Don't modify user accounts."
Good blacklist: "Never change billing status, user permissions, account limits, or subscription tiers. If a user requests account changes, create a support ticket with category 'account-modification' and explain they'll hear back within 4 hours."

The good version tells the agent exactly what constitutes "modification" and exactly what to do instead. No ambiguity, no creative interpretation.

We also learned to blacklist by outcome, not just action:

• Action blacklist: "Don't use the billing API"
• Outcome blacklist: "Never take any action that could change what a customer pays or when they pay it"

The outcome version catches edge cases. Maybe there's a promotional credit API you forgot about. Maybe there's a subscription pause feature. The outcome blacklist catches all paths to the same bad result.

Here's our current governance template:

## HARD BOUNDARIES (Never do this)
- [Specific actions that could cause damage]

## SOFT BOUNDARIES (Escalate instead)
- [Actions that need human judgment]

## COMMUNICATION BOUNDARIES (Never say this)
- [Phrases that could create legal/business problems]

## CONTEXT BOUNDARIES (Don't share this)
- [Internal information that shouldn't leave the company]

The communication boundaries piece is crucial. Your agent might never break your systems, but it could still cause problems by promising things you can't deliver or sharing information you shouldn't.

We blacklist phrases like "I'll make sure that gets fixed" (promises we can't guarantee) and "Let me check our internal systems" (reveals architecture details).

Most importantly: test your blacklists with adversarial prompts. Don't just check if your agent follows the rules. Check if it follows them when a user is actively trying to get around them.

The best governance isn't about building perfect guardrails. It's about building clear escalation paths so your agent knows exactly what to do when it hits the edge of its authority.