Authorization Boundaries for Security AI Agents: Engineering Red Team Capabilities as APIs

1. Reframing the Problem: When Red Team Capabilities Become Callable Interfaces

Traditional red team work relies on expert experience, manual tooling, and staged exercises. Capability lives in people, and risk is mostly controlled by people. When vulnerability discovery, exploit validation, and attack path inference are packaged into model services and APIs, security teams gain a higher degree of automation and a lower invocation barrier—but they also introduce agents that can write attack code into engineering systems. At this point, the core question is no longer whether the model can find vulnerabilities, but within what scope the model discovers, against which targets it validates, in which environment it executes, who reviews the results, and who signs off on the fix.

A scoped security agent is therefore not a general-purpose model with a security system prompt. It is high-risk capability wrapped inside a controlled execution framework: the authorization context defines who can do what; the policy engine decides whether the current request crosses a boundary; the tool layer limits which targets can be reached; the sandbox isolates execution side effects; the audit chain records evidence for every step; and human review determines whether a result enters the remediation workflow. The stronger the capability, the more front-loaded the boundary must be. The more general the interface, the more fine-grained the authorization needs to be.

2. Key Design Principles: Scope as Guardrails

2.1 Authorization Is an Executable Policy Object, Not a Promise

The authorization scope of a security agent should be modeled as a structured object rather than described in natural language. At minimum, it should include principal, purpose, target assets, allowed actions, denied actions, time window, rate limit, execution environment, and evidence requirements. This allows the policy layer to perform deterministic validation before every tool call, preventing out-of-scope behavior caused by model misinterpretation.

Example authorization context:

{
  "principal": "authorized-research-team",
  "purpose": "authorized-vulnerability-review",
  "targets": ["asset-group-a"],
  "allowed_actions": ["discover", "validate-in-sandbox"],
  "denied_actions": ["persist", "lateral-move", "data-exfiltration"],
  "window": "2025-01-01T00:00Z/2025-01-02T00:00Z",
  "rate_limit": "conservative",
  "environment": "isolated-sandbox",
  "evidence_required": true
}

Policy validation should follow a default-deny, explicitly-allowed model:

function authorize(request, grant):
    if request.target not in grant.targets:
        deny("out-of-scope-target")
    if request.action not in grant.allowed_actions:
        deny("action-not-authorized")
    if now() outside grant.window:
        deny("authorization-expired")
    if request.environment != "isolated-sandbox":
        require_approval("non-sandbox-execution")
    if request.action in irreversible_actions:
        require_two_person_rule()
    return allow_with_full_audit(request)

The value of this kind of policy object is that it is auditable, testable, and reversible. Security teams can test authorization rules as they would test code, covering scenarios such as expired authorization, out-of-scope targets, unauthorized actions, and environment violations.

2.2 Boundary-Keeping Rate Matters More Than Attack Success Rate

When evaluating a security agent, metrics should not be limited to the number of vulnerabilities found or the exploit validation success rate. Boundary-keeping performance under boundary-trap tests matters just as much. Public materials indicate that a category of specialized security models has improved significantly over the previous generation in authorized tasks: the boundary-keeping rate reached nearly 99.9% in un-prompted boundary traps and 100% in prompted conditions. The engineering significance of these numbers is not about ranking; it is that capability evaluation must include both how much the model can do and how much the model refuses to do.

A more complete metric system should include in-scope discovery rate, validation success rate, false positive rate, boundary interception rate, prompt injection resistance, evidence completeness rate, remediation closure rate, average review time, and human override rate. A single metric can easily push teams toward stronger attack power while neglecting boundary costs. For a system that can actually be deployed, boundary interception, audit completeness, and human review should be treated as hard gate requirements.

2.3 Real Samples Show High-Risk Surfaces Require Isolated Validation

Public materials describe exercises covering high-risk surfaces such as browsers and operating system kernels, which produced dozens of previously unknown high-severity vulnerabilities and hundreds of privilege escalation samples. This result shows that once a security agent has vulnerability discovery and exploit validation capabilities, its output is not just a report—it may contain executable attack paths. Therefore, validation must be completed in an isolated environment where samples, credentials, network egress, and file systems are all controlled. Discovery can be automated; validation must be sandboxed; fix recommendations must be reviewed by humans.

3. Engineering Architecture: A Five-Layer Guardrail for an Operable Closed Loop

3.1 Authorization Layer: Tickets, Scope, and Revocation

The authorization layer should be integrated with enterprise ticketing, asset registries, and identity systems. Every call is bound to an authorization ID, a target asset group, a validity period, allowed actions, and a responsible person. When an authorization is revoked, running tasks should be terminated immediately and temporary credentials invalidated. For critical infrastructure targets, two-person approval and purpose restrictions should be added, and authorization must not be expanded to unregistered assets.

3.2 Policy Layer: Policy as Code with Default Deny

The policy layer is responsible for turning authorization objects into enforceable decisions. Policy as code is the recommended approach: all rules enter version control, and changes require review. Policies should cover target whitelists, action whitelists, time windows, rate limits, environment constraints, irreversible operations, sensitive data access, and external network access. Model output should be treated only as a request suggestion; it must not be able to bypass the policy layer.

3.3 Execution Layer: Sandboxed Runtime and Least-Privilege Credentials

The execution layer should use isolated containers or temporary compute environments. Network egress is off by default and opened on demand only to authorized targets. Credentials should be short-lived, least-privilege, and read-only where possible. File systems should be temporary mounts that are destroyed after the task ends, and direct connection to production environments is forbidden. When deploying in an enterprise cloud environment, teams may use general-purpose capabilities such as the container platform, log service, and monitoring/alerting provided by Baidu AI Cloud to host the isolated execution and audit pipeline; the specific configuration should follow the enterprise security baseline.

3.4 Validation Layer: Discovery—Reproduction—Assessment—Fix—Regression

The output of a security agent must pass through a validation loop: after a suspicious issue is discovered, it should be minimally reproduced in a sandbox; the impact scope and trigger conditions should be assessed; fix or mitigation recommendations should be generated; humans should confirm the patch and the change window; and regression validation should be performed after the fix. The validation layer should retain evidence hashes, environment snapshots, input/output, and review records, so that a claim that the model found a vulnerability cannot directly enter production changes.

3.5 Audit Layer: Full Logging and a Traceable Evidence Chain

The audit layer should record prompts, tool calls, targets, parameter summaries, returned results, file hashes, network metadata, policy decisions, and human approvals. Logs should be desensitized, access-restricted, and retained for a defined period. Audit is not a post-hoc ledger but a real-time risk signal: when a boundary refusal, abnormal request rate, sensitive path access, or prompt injection signature appears, the system should raise an alert and trigger a circuit breaker.

4. Integration into Routine Vulnerability Inspection

Security teams can integrate a controlled security agent into routine inspection workflows, but the path should follow this progression: shadow environment first, then authorized access, then production-adjacent scope. Step one is to validate the process in a shadow or cloned environment. Step two is to open read-only discovery capability for low-risk asset groups. Step three is to open validation capability under explicit authorization and sandbox conditions. Only then should integration with patch management and ticketing systems be considered. At no stage should an agent be allowed to connect directly to a production environment for exploit validation.

Inspection tasks should use conservative rate limits, fixed time windows, and explicit asset lists to avoid disturbing business operations. Fix recommendations generated by the model must be reviewed by security engineers and business owners; patches require signing, change approval, and a rollback plan. For high-severity vulnerabilities, mitigation measures and staged validation should be preferred over one-time, large-scope changes.

5. Risk Boundaries: Where Is the Gate for Dual-Use Capabilities?

Red team capabilities are inherently dual-use. The governance gate can be reduced to four questions: Who is authorized? What is tested? Is it sandboxed? Who signs off on the patch?

• Who is authorized determines the calling party and the approval chain.
• What is tested determines the target whitelist and action whitelist.
• Is it sandboxed determines execution isolation and network boundaries.
• Who signs off on the patch determines remediation responsibility and change control.

Automated validation capability should not be enabled until these four questions have clear answers.

Additional risks must also be addressed: untrusted model output, tool description pollution, prompt injection, privilege escalation chains, and sensitive data leakage. Every tool call should pass through the policy layer; the model must not be able to expand the target scope on its own; external input should be isolated and marked; irreversible operations should require second confirmation; and sensitive information should be collected on a minimal basis. In the future, the core skill of security roles may not be writing every piece of attack code manually, but designing and operating an authorization, isolation, audit, and validation system that manages the AI that can write attack code.

6. Landing Checklist

1. Is a structured authorization object established and bound to a ticket and a responsible person?
2. Are unregistered targets and unauthorized actions denied by default?
3. Is sandbox execution mandatory with network egress off by default?
4. Are short-lived, least-privilege credentials used?
5. Are all tool calls and policy decisions recorded in full?
6. Are alerts configured for boundary refusals, abnormal rates, and sensitive access?
7. Do vulnerability conclusions and fix recommendations require human review?
8. Do patches carry signing, approval, and rollback plans?
9. Are expired authorization, out-of-scope targets, and prompt injection scenarios tested regularly?
10. Is there a mechanism that terminates running tasks and invalidates credentials when authorization is revoked?

Conclusion

Turning red team capability into an API is not the end goal. The real engineering challenge is to confine the capability inside verifiable boundaries: authorization scope is the guardrail, the sandbox is the isolation zone, audit is the evidence chain, and human review is the last gate. Only when discovery, validation, fix, and regression form a closed loop can a security agent move from being a demo capability to becoming operable security infrastructure.