Agent Sandbox Container Edition: Defense-in-Depth Security for Enterprise AI Agents

Introduction: The Shift to Autonomous Agent Attacks

Attackers now use fully autonomous agents that can orchestrate scans, call tools, adjust based on results, and manage credentials without human intervention. Enterprises simultaneously grant their own agents capabilities to read documents, execute code, call APIs, and operate cloud resources. This shared autonomy means a single over‑permissioned credential or a prompt‑injection‑induced tool call can escalate into data exfiltration. Model‑level refusal alone is insufficient; a layered security architecture is required.

Identity and Credentials: No Long‑Lived Secrets, No Over‑Permission

The Problem: Static Credentials in a Dynamic World

A typical scenario: an agent needs to check ACK cluster status. Someone puts an Alibaba Cloud AccessKey (AK) into an environment variable. Months later that AK appears in logs, in a prompt‑injection‑induced output, in a debug script written by the agent itself. The key never expires, its copies are untraceable, and rotation forces all agents to stop.

The root cause is not agent mistakes but the wrong credential shape. Traditional microservices assume stable callers, trusted code, and self‑representing behavior. Agents break all three: sandboxes are ephemeral, LLMs leak keys into logs and can be tricked into exfiltration, and each invocation may represent a different user, CLI, or background service.

Platform‑Level Credential Management via ack‑agent‑identity

Agent Sandbox Container Edition introduces the ack-agent-identity CredentialProvider to centralize credential governance:

Integrates Kubernetes Secrets, KMS Credential Manager, and RAM Role STS temporary credentials.

Binds credentials to agent identities with fine‑grained authorization ( AgentRole / AgentRoleBinding).

Egress gateway injects real credentials at the network edge; applications only handle placeholder credentials, avoiding exposure in business code or runtime environments.

For cloud resources, RRSA issues short‑lived STS tokens on demand with automatic rotation; session policies further restrict permissions to the sandbox instance’s required resource scope.

For API keys, dynamic selection per identity and KMS‑backed centralized management, rotation, and auditing are supported.

The principle: minimize key exposure, bind access to identity, enforce least privilege, shorten credential lifetime .

OAuth 2.0 Three‑Legged Delegation: Dynamic Identity for Agents

When agents act on behalf of users to access documents, code repositories, or enterprise apps, the goal is not “give the agent a key” but “let the agent prove who sent it, who it is, and whether the door is still open.” The sandbox provides two delegation modes via ack-agent-identity:

UserFederation (Authorization Code + PKCE) for web, console, and IDE scenarios — presents the requesting agent and required scopes to the user for explicit consent.

DeviceCode (RFC 8628) for headless CLI sandboxes — user completes login/authorization on a separate device; no browser or callback endpoint needed inside the sandbox.

Both modes keep application secrets, refresh tokens, and device codes on the trusted control plane; sandboxes receive only short‑lived access tokens. Combined with workload‑identity authentication and AgentRole / AgentRoleBinding, this replaces “handing long‑lived keys to agents” with “agents obtain access through explicit, auditable delegation.”

Baseline Security: Storage and Network Hardening

Storage: Sandbox Holds No Long‑Term Keys

Data security is paramount. Agent Sandbox replaces static AccessKeys with Agent Identity (RRSA + STS) , issuing each sandbox an independent identity that dynamically obtains short‑term STS tokens, achieving instance‑level permission isolation.

Two challenges addressed:

Tenant‑level least privilege : A two‑layer model — RRSA grants maximum storage permissions to the control‑plane plugin; CredentialProvider declares per‑tenant minimum permissions. The issued token is the intersection, scoped to a specific subpath.

Scalable authorization : SandboxClaim dynamic parameters combined with policy template functions let administrators avoid defining countless per‑subpath policies; each sandbox instance receives a uniquely scoped STS token.

Production best‑practice checklist:

Use subPath + independent CredentialProvider for tenant data isolation.

Adopt Agent Identity (RRSA + STS) — no long‑lived credentials in the sandbox. ListObjects requires oss:Prefix Condition.

Mount OSS via HTTPS internal endpoint with SigV4 signing.

Shared storage default readOnly: true.

Network: Layered Policies for “Default Deny, Precise Allow”

Network sniffing and egress are primary attack vectors. The platform classifies workloads into three trust levels; sandbox compute is explicitly marked untrusted. Multi‑tenant sandboxes get dedicated vSwitches and enterprise security groups for network‑level isolation.

Policy primitives: TrafficPolicy — L4 ingress/egress rules per application (IP CIDR, Service, FQDN, port). GlobalTrafficPolicy — Cluster‑wide baseline for sandbox traffic. SecurityProfile — L7 control via auto‑injected traffic-proxy sidecar and centralized egress-gateway evaluation. Capabilities include:

TLS termination (HTTPS inspection transparent to apps) via auto‑injected CA certs and env vars SSL_CERT_FILE, NODE_EXTRA_CA_CERTS.

MCP tool‑level granular access control.

Credential injection and request re‑signing bound to declared egress destinations and headers.

Webhook integration for custom audit, monitoring, and alerting.

E2B interface hardening: clients obtain sandbox‑scoped JWT dynamic tokens; gateway validates them, mitigating static token leakage risks.

Network best‑practice checklist:

Enable enhanced-traffic-policy for L4+L7 incremental policies.

Default deny internal access to prevent lateral movement.

Use independent enterprise security group + intra‑group isolation + port matrix.

Public egress: SecurityProfile whitelist mode allowing only known safe domains. GlobalTrafficPolicy blocking metadata service 100.100.100.200.

Enable JWT dynamic token authentication on SandboxGateway; separate control‑plane and data‑plane traffic.

Drop RAW_NET capabilities to prevent traffic sniffing/hijacking.

Baseline Drift Detection: ack‑agent‑sec‑scanner

Documented best practices (37 items) do not guarantee runtime compliance. Configurations drift: GlobalTrafficPolicy metadata hard‑blocks commented out during debugging; CredentialProvider policies widened to "Resource": "*" for velocity. These cause no errors but leave gaps. Additionally, third‑party Skills and MCP Servers may carry malicious logic or excessive permissions. ack-agent-sec-scanner addresses this from two directions:

Pre‑admission scan : Static analysis of uploaded Skill/MCP Server artifacts — detects malicious code, dangerous commands, credential leaks, prompt injection, over‑permission requests, and governance policy defects. Outputs security score and per‑finding remediation.

Post‑admission inspection : Periodic reads of cluster resources ( Sandbox, SandboxSet, SecurityProfile, TrafficPolicy, CredentialProvider, AgentRole, PersistentVolume) and asserts compliance against the Agent Sandbox Security Best Practices guide, identifying runtime drift.

Rules align with OWASP Top 10 for Agentic Applications 2026 (ASI) as the sole threat baseline; each finding carries an ASI category code (e.g., ASI05 / Unexpected Code Execution). Gaps are acknowledged: ASI07/08/10 (inter‑agent communication, cascading failures, rogue agents) are marked as having no static rule coverage because they belong to runtime guardrail and eBPF kernel‑level detection domains.

Governance interfaces: interactive console, automation API (embeddable in CI/CD admission gates — fail blocks deployment), and report export. Screenshot of scanner dashboard included.

Runtime Security: Asset Visibility, Guardrails, and Kernel‑Level Observability

AI Asset Center: Unified Security Posture

Security starts with visibility. The Alibaba Cloud Agent Security Center’s AI Asset capability aggregates AI workloads, container images, AI services, and tool components into a single view. Asset sync and detection services surface vulnerabilities, misconfigurations, public exposure, and plaintext key risks. Three questions answered:

Which assets need priority attention? (Risk asset count and trend.)

Where does risk originate? (Top AI vulnerabilities, config risks, public exposure, plaintext keys.)

What to fix next? (Asset‑level risk details and remediation guidance.)

For Agent Sandbox workloads, Serverless does not mean security‑invisible . Enable Cloud Security Center’s Serverless security by declaring label security.alibabacloud.com/aliyundun-enabled: "true" in the sandbox template. Sandbox threats and asset data then appear in the Cloud Security Asset Center. Screenshot of asset overview included.

Agent Security Center: Guardrails for Every Interaction

Dangerous inputs hide in normal workflows: indirect instructions in web pages, role‑playing in tool returns, refusal‑suppression phrases in Skills, encoded malicious requests. The AI Safety Guardrail covers prompt injection/jailbreak, content compliance, sensitive data leakage, behavior deviation/goal hijacking, and model resource abuse. On supported ingestion paths it can alert, warn, or block.

Integration example: an openclaw app deployed in Agent Sandbox. Enable ack-onepilot via labels:

<code>raspPilotAutoEnable: "on"/code>

raspPilotAmsKey: "<access‑key>"

raspPilotLang: "nodejs"

raspPilotRegion: "cn|abroad"

After sandbox update, RASP probe injects automatically. Real‑time guardrail blocks an obfuscated malicious link in a prompt, preventing behavior deviation. Screenshot of blocked attempt shown. The Agent Risk page aggregates events, provides remediation recommendations, and allows dismissal of assessed risks with re‑scan verification. Screenshot included.

Agent Observability: From Audit Logs to eBPF Execution Evidence

Users see a final answer; the agent may have executed dozens of model calls and tool operations. Cloud Security Agent Audit Logs record runtime behavior, network communication, and security events across Agent, Trace, Model, and Tool dimensions — providing context for anomaly investigation and performance debugging. Screenshot of audit dashboard included.

For custom audit/monitoring, Agent Sandbox offers an Egress Gateway Audit Webhook : on SecurityProfile rule match, outbound requests are POSTed to an external service for integration with internal SIEM, alerting, or notification pipelines.

When agents spawn scripts or third‑party binaries, model‑level logs are insufficient. Cilium Tetragon eBPF observability collects process, file, network, and sensitive syscall events at designated kernel probe points without requiring application‑level instrumentation or uniform SDK adoption across every derived tool.

In Agent Sandbox’s current adaptation, Tetragon runs as a sidecar in the sandbox guest kernel, loading eBPF programs. Declarative TracingPolicy defines probe points, match conditions, and actions, enabling version‑controlled, scenario‑specific observability. Typical scenarios:

Process behavior : exec, exit, parent‑child relationships — traces agent‑spawned scripts/tools.

File behavior : deletions, writes to sensitive paths — detects config tampering and data destruction.

Network behavior : TCP connections with address/port metadata — locates anomalous external contacts.

Sensitive syscalls : setuid, ptrace, etc. — provides attack‑chain forensic evidence.

Tetragon’s Prometheus endpoint integrates with ARMS auto‑discovery for self‑monitoring; kernel events export as JSON to SLS for querying. Screenshot of a Tetragon SIGKILL interception log query shown.

Trade‑off: Tetragon requires privileged mode. It runs in an isolated, single‑purpose container without sharing the PID namespace, balancing observability gain against attack surface increase.

Guardrail benchmarks show < 100% block rates, especially for long‑horizon and composite attacks. Audit logs capture which tools were called ; Tetragon captures what processes, files, and network connections those tools triggered . The two perspectives complement each other. Screenshot of combined view included.

Summary: A Cohesive Defense‑in‑Depth Framework

Enterprises trust agents with real tasks not because models “won’t make mistakes” but because a security fabric spans identity, permissions, and execution:

Foundational boundaries : Isolated compute, network access control, storage least privilege; continuous asset inventory and baseline scanning.

Identity & credential unity : Agent Identity + CredentialProvider for centralized secrets; UserFederation / DeviceCode OAuth delegation for explicit, scoped, short‑lived access.

Runtime protection : AI guardrails detect prompt injection, data leakage, goal hijacking; Tetragon eBPF adds kernel‑level process/file/network evidence; audit logs, SLS, and ARMS enable investigation, hardening, and verification of protective efficacy.

These layers are not redundant switches but complementary defense lines: Identity answers “who are you and who do you represent?”, Baseline defines “what can you reach and do?”, Runtime protection asks “what actually happened and how do we detect and respond?”. The result: agents operate autonomously with every authorization grounded, every risk constrained, and every critical action traceable.