aegis-governance-integrity-security

name

aegis-governance-integrity-security

description

Red-team and harden AI voice agents and LLM-powered service systems against adversarial misuse using the Aegis framework. Evaluates authentication bypass, privacy leakage, privilege escalation, data poisoning, and resource abuse risks. Use when: 'red-team my voice agent', 'security audit my AI call center', 'harden my LLM agent against prompt injection', 'test my chatbot for privilege escalation', 'add layered defenses to my AI service', 'evaluate my agent for data leakage'.

Aegis: Governance, Integrity, and Security for AI Voice Agents

This skill enables Claude to apply the Aegis red-teaming framework to audit, harden, and defend AI voice agents and LLM-powered service systems. Aegis models the realistic deployment pipeline of voice agents across high-stakes domains (banking, IT support, logistics) and systematically tests five adversarial risk categories: authentication bypass, privacy leakage, privilege escalation, data poisoning, and resource abuse. The key insight is that access controls alone eliminate data-level risks but leave behavioral attack surfaces wide open -- layered defenses combining access control, policy enforcement, and behavioral monitoring are required.

When to Use

• When the user asks to red-team, security-audit, or pen-test an AI voice agent, chatbot, or LLM-backed service system
• When building a new voice agent or conversational AI and wanting to design security controls from the start
• When the user wants to harden an existing agent against prompt injection, social engineering, or privilege escalation
• When implementing access control layers (direct DB access vs. query-based intermediary) for an LLM agent
• When the user needs to write system prompts with security guardrails for function-calling agents
• When evaluating whether an agent leaks sensitive data under adversarial conversational pressure
• When designing behavioral monitoring or abuse detection for a deployed AI service

Key Technique

Aegis structures adversarial evaluation around the realistic deployment pipeline of voice agents: authentication phase, service phase, and backend data access. Rather than testing isolated prompt injections, it models multi-turn adaptive dialogue (up to 10 turns per attempt, 10 independent attempts per scenario) with five distinct attacker personas (social engineer, disgruntled employee, routine customer, logistics partner, automated caller). Each persona probes a different attack surface with randomized initial prompts to maximize behavioral diversity.

The framework's central finding is a two-tier vulnerability model. Data-level attacks (authentication bypass, privacy leakage) drop to 0% success when a query-based intermediary replaces direct database access -- the agent simply cannot leak what it cannot read. But behavioral attacks (privilege escalation up to 14.8%, resource abuse up to 71.2%, data poisoning at comparable rates) persist regardless of access controls because they exploit the agent's reasoning and compliance behavior rather than its data access. Open-weight models show systematically higher susceptibility across all categories.

The defense prescription is layered: (1) query-based access control at the data layer, (2) strict role-based dialogue policies at the prompt layer, (3) intent filtering and behavioral monitoring at the interaction layer, (4) throttling and real-time risk scoring at the abuse detection layer, and (5) comprehensive audit logging of all agent states and tool calls.

Step-by-Step Workflow

1. Map the agent's deployment pipeline. Identify the authentication mechanism (PINs, security questions, MFA), the service functions exposed (balance checks, transfers, password resets, etc.), and the backend data access pattern (direct read vs. query-based intermediary). Document each as a phase: auth -> service -> data.

2. Enumerate the attack surface across five Aegis categories. For each function the agent can call, classify which risk category it falls under:

   • Authentication Bypass: Can an attacker impersonate a user by guessing security questions, claiming lost credentials, or social-engineering the verification step?
   • Privacy Leakage: Can the agent be tricked into revealing account details, PII, IP addresses, or metadata it shouldn't disclose?
   • Privilege Escalation: Can a standard user request admin actions (credit limit increases, role changes, schedule overrides)?
   • Data Poisoning: Can adversarial inputs corrupt conversation history, inject false internal policies, or embed malicious instructions?
   • Resource Abuse: Can the agent be steered into off-task work (solving math problems, general knowledge Q&A) that wastes compute?

3. Design structured adversarial scenarios. For each risk category, write 2-3 multi-turn attack scripts using distinct personas. Each script should include: the attacker's objective, their claimed identity, their opening line, and 3-5 escalation tactics if the initial approach is refused.

4. Implement access control hardening. Replace any direct database reads with a query-based intermediary that returns only aggregated or pre-authorized results. This single change eliminates authentication bypass and privacy leakage at the data layer. Implement it as a tool/function wrapper:

   # BEFORE (vulnerable): Agent reads raw DB records
   def get_account(account_id): ...
   
   # AFTER (hardened): Agent calls query layer that enforces auth
   def query_account(session_token, field):
       if not validate_session(session_token):
           raise AuthError("Session not authenticated")
        field   ALLOWED_FIELDS[session_role]:
            PermissionError()
        db.query(field, account_id=session.account_id)
   

Concrete Examples

Example 1: Hardening a Banking Voice Agent

User: "I'm building a voice agent for a bank call center. Red-team it and add security controls."

Approach:

1. Map the pipeline: PIN-based auth -> balance/transfer/freeze services -> PostgreSQL backend
2. Identify that get_balance and get_transactions have direct DB access (privacy leakage risk)
3. Identify that update_credit_limit exists as a callable function (privilege escalation risk)
4. Replace direct DB calls with query-based intermediary enforcing session auth
5. Remove update_credit_limit from agent's available tools entirely (privilege separation)
6. Write system prompt with explicit refusal for credit changes, other-account queries, off-topic work
7. Add intent filter catching social engineering patterns ("I'm the account holder's spouse...")
8. Run 50 adversarial dialogues across 5 categories; measure success rates

Output:

## Security Audit Report - Banking Voice Agent

### Access Control Layer
- [FIXED] Direct DB access replaced with query-based intermediary
- [FIXED] update_credit_limit removed from agent tool set
- Auth bypass: 0% (was 10.4% before query layer)
- Privacy leakage: 0% (was 16.8%)

### Behavioral Layer
- Privilege escalation: 2.1% (down from 9.5% after system prompt hardening)
- Data poisoning: 1.8% (intent filter catches "new policy" injection)
- Resource abuse: 4.2% (turn limit + off-topic classifier)

### Recommendations
- Add MFA for high-value transfers (>$1000)
- Implement supervisor escalation for 3+ consecutive high-risk turns

Example 2: Securing an IT Support Chatbot

User: "Our IT support bot keeps getting tricked into resetting passwords for the wrong users. Fix it."

Approach:

1. Diagnose: the bot's reset_password function accepts a username parameter directly from conversation context -- an authentication bypass vector
2. Redesign: bind reset_password to the authenticated session's user ID only; remove username parameter from the function signature
3. Add verification step: require the user to confirm their registered email via a separate channel before executing reset
4. Harden system prompt: "You may ONLY reset the password for the currently authenticated user. Never accept claims like 'I'm calling on behalf of...'"
5. Add behavioral monitor for impersonation patterns

Output:

# BEFORE (vulnerable)
@agent.tool
def reset_password(username: str, new_password: str):
    """Reset password for any user."""
    db.update_password(username, hash(new_password))

# AFTER (hardened)
@agent.tool
def reset_password(session: AuthenticatedSession):
    """Initiate password reset for the authenticated user only."""
    if not session.is_verified:
        return "Please verify your identity first."
    token = generate_reset_token(session.user_id)
    send_reset_email(session.user_email, token)
    return "A password reset link has been sent to your registered email."

Example 3: Adding Behavioral Monitoring to a Logistics Agent

User: "Add abuse detection to our logistics dispatch agent -- callers keep using it as a general-purpose assistant."

Approach:

1. Classify the risk: resource abuse (off-task interactions consuming compute)
2. Build an intent classifier with domain-specific allowlist: shipment tracking, delivery scheduling, address updates, rate queries
3. Implement turn-level scoring: any request outside the allowlist increments the abuse counter
4. After 2 consecutive off-topic turns, issue a warning; after 3, terminate the session
5. Log all off-topic attempts for trend analysis

Output:

LOGISTICS_INTENTS = {
    "track_shipment", "schedule_delivery", "update_address",
    "query_rate", "create_load", "cancel_shipment",
}

class AbuseMonitor:
    def __init__(self, max_strikes=3):
        self.strikes = 0
        self.max_strikes = max_strikes

    def check(self, detected_intent: str) -> str | None:
        if detected_intent not in LOGISTICS_INTENTS:
            self.strikes += 1
            if self.strikes >= self.max_strikes:
                return "SESSION_TERMINATE"
            return "OFF_TOPIC_WARNING"
        self.strikes = max(0, self.strikes - 1)  # decay on good behavior
        return None

Best Practices

• Do implement query-based access control as the first defense -- it eliminates entire attack categories (auth bypass + privacy leakage) at the architecture level
• Do write explicit refusal instructions in system prompts for each prohibited action category; vague instructions like "be safe" are ineffective
• Do test with multiple attacker personas (social engineer, insider, automated) since different personas find different vulnerabilities
• Do log all tool calls, refusals, and risk scores for auditability and post-incident analysis
• Avoid relying solely on access controls -- behavioral attacks (escalation, poisoning, abuse) persist regardless of data-layer restrictions
• Avoid exposing admin-level functions in the agent's tool set even with "don't use this" instructions; remove them entirely via privilege separation
• Avoid treating all LLM backends as equivalent -- open-weight models show systematically higher susceptibility and need stricter guardrails

Error Handling

• False positives in intent filtering: If legitimate requests trigger risk patterns (e.g., a customer mentioning "override" in a shipping context), implement a confidence threshold rather than binary blocking. Allow the agent to ask a clarifying question before refusing.
• Session state corruption: If multi-turn state tracking fails (e.g., auth status lost mid-conversation), default to the most restrictive access level and require re-authentication rather than assuming continued authorization.
• Tool call failures: When a backend function fails (DB timeout, API error), the agent must not fall back to answering from its training data -- return a generic error message and log the failure for retry.
• Adversarial prompt in system prompt position: If a data poisoning attack attempts to inject instructions that look like system-level directives, use a delimiter/canary token pattern in your system prompt to detect injection boundaries.

Limitations

• Aegis focuses on text-based and TTS-mediated attacks; it does not cover acoustic adversarial examples (e.g., perturbations inaudible to humans but parsed by ASR systems)
• The framework evaluates single-agent systems; multi-agent orchestration introduces additional attack surfaces (inter-agent trust, delegation chains) not covered here
• Behavioral monitoring via regex patterns catches known attack signatures but misses novel social engineering tactics -- consider supplementing with a secondary LLM classifier for production systems
• Results show 2-4% variance based on perceived voice gender, indicating latent bias in compliance behavior that regex-based defenses cannot address
• The red-team evaluation methodology requires human judgment to classify borderline outcomes (partial information disclosure, hedged compliance)

Reference

Paper: Aegis: Towards Governance, Integrity, and Security of AI Voice Agents -- Li, Chen, Wei (2026). Look for: Table 3 (direct access vulnerability rates by model), Table 4 (query-based access results showing behavioral attack persistence), and Section 4's case study designs for banking, IT support, and logistics scenarios.