AI Agent 权限设计：为自主 AI 构建安全访问控制

AI Agent Permissions: Designing Secure Access for Autonomous AI 1. The Authorization Problem of Autonomous AI Systems Traditional applications operate within deterministic execution paths. Request routing, database queries, and downstream API invocations are hard-coded by software engineers, ensuring that every code branch has a known, reviewable blast radius. Autonomous AI systems fundamentally break this traditional authorization paradigm. When deploying large language models with tool execution capabilities—similar to those examined in AI Agent Tool Calling How LLMs Decide Which APIs and Actions to Execute—the model dynamically selects APIs, constructs SQL statements, and chains multi-step workflows at runtime based on natural language inputs. This dynamic agency introduces severe operational challenges: Model-Driven Tool Selection: The control flow is determined by stochastic transformer generations rather than compiled abstract syntax trees. Multi-System Aggregation: A single agent session may traverse identity providers, customer relationship management (CRM) systems, cloud object stores, and internal microservices. Incomplete Consequence Modeling: Models frequently fail to evaluate the secondary and tertiary side effects of an asynchronous, multi-step execution chain. Without dedicated architectural boundaries, giving an autonomous system access to enterprise tools is functionally equivalent to granting arbitrary remote code execution to an untrusted user. 2. Authentication vs. Authorization vs. Agent Execution Scope Securing autonomous workflows requires separating distinct trust boundaries. Conflating these layers is the root cause of widespread credential leakage and privilege escalation. +---------------------------------------------------------------------------------+ | IDENTITY LAYERS | | | | [ Authentication ] ---> Who is making the request? (User/Service Principal)| | │ | | ▼ | | [ Authorization ] ---> What is that identity allowed to do globally? | | │ | | ▼ | | [ Agent Scope ] ---> What is THIS specific agent execution permitted | | to touch for THIS specific user task? | +---------------------------------------------------------------------------------+ Enter fullscreen mode Exit fullscreen mode Authentication Authentication verifies the provenance of the request. In human-in-the-loop agent interactions, this validates the end-user via OpenID Connect (OIDC) or OAuth 2.0 access tokens. For background worker agents, this authenticates the service principal or worker daemon via mutual TLS (mTLS) or signed JSON Web Tokens (JWTs). Authorization Authorization determines whether an authenticated entity possesses the static role-based access control (RBAC) or attribute-based access control (ABAC) permissions to interact with a specific resource or database table. Agent Execution Scope Agent execution scope answers a dynamic question: Given that user U has permission P, and agent A is executing task T, what subset of permissions should be active during this specific tool invocation loop? Preserving the explicit chain of custody among the human requester, the agent runtime, the active task context, and the target tool is mandatory. If an agent executes actions using a static, highly privileged service account, the relationship between the human user and the target resource is entirely severed, rendering audit logs and tenant boundaries useless. 3. Least Privilege for AI Agents Applying least-privilege principles to autonomous systems requires shifting away from broad, service-level grants toward highly scoped, task-specific capabilities. The Anti-Pattern: Unrestricted Service Accounts In naive implementations, developers provision an agent with a broad database connection string, an unrestricted API token, or a cloud service principal with administrative permissions across multiple projects. $$\ text{Access}{\text{naive}} = {\text{DB}{\text{read/write}}, \text{Cloud}{\text{admin}}, \text{Internal}{\text{APIs}}}$$ If a prompt injection payload alters the model's objective, the blast radius encompasses the entire infrastructure. The Production Pattern: Scoped Contextual Access Production-grade architectures isolate access across discrete system boundaries: APIs: Limited to specific, idempotent endpoints rather than general-purpose CRUD controllers. Databases: Restricted to read-only views or parameterized stored procedures mapped to tenant-specific partitions. Cloud Resources: Bounded by temporary IAM session policies whose duration matches the expected lifetime of the task loop (e.g., maximum 15 minutes). Secrets: Isolated via credential brokers that inject ephemeral tokens directly into the tool execution boundary without exposing raw secrets to the model context window. 4. Capability-Based Permissions and Risk Classification Rather than relying on coarse-grained system roles, modern agent runtimes implement capability-based security models. Instead of passing an unrestricted API key to an agent, the runtime exposes discrete, highly specialized tool functions. Capability Granularity Compare broad system access with capability-scoped tool registration: Permission Model Agent Access Policy Control Primary Operational Risk Broad Service Account Wide Low Complete infrastructure compromise upon prompt injection User Credentials User-level Medium Credential exposure and session hijacking Scoped Credentials Limited High Scope configuration drift and token management overhead Capability-Based Tools Action-specific High Tool design complexity and schema explosion Policy + Approval Dynamic High Operational latency and user fatigue Risk-Tiered Action Classification To govern execution flows effectively, every tool registered with an agent must belong to a distinct risk class: Read Actions ($R$): Operations like retrieve, search, and inspect. These carry low blast radius and are typically executed asynchronously without manual gating. Write Actions ($W$): Operations like create, update, and send. These require tenant isolation checks and strict input validation schemas. Destructive Actions ($D$): Operations like delete, revoke, deploy, and modify infrastructure. These mandate explicit human-in-the-loop approval gates before execution. 5. The Policy Engine and Architecture Reference To intercept unauthorized actions before they reach downstream systems, the execution flow must pass through a centralized policy evaluation layer. This pattern decouples agent intent from system enforcement. +-------------+ +-------------------+ +------------------+ | User Request| ---> | Agent Runtime | ---> | Policy Engine | +-------------+ | (LLM + Plan Loop) | | (OPA / Cedar) | +-------------------+ +------------------+ │ │ ▼ ▼ +-------------------+ +------------------+ | Tool Registry | Evaluates User Scope & Risk Level │ ├─────────────────────────────► [ DENY: User lacks admin role ] │ ▼ [ Execution Blocked (Zero Trust Enforced) ] Enter fullscreen mode Exit fullscreen mode By enforcing strict capability boundaries at the API gateway and policy engine, an injected prompt cannot execute actions outside the pre-authenticated scope of the invoking user and task. 7. Credential Isolation\, Sandboxing\, and Tenant Boundaries Production architectures must assume that the model weights and agent runtimes are untrusted execution environments. Defense-in-depth requires rigorous hardware and software isolation. Credential Isolation Models must never possess raw API keys, master OAuth refresh tokens, or administrative service account credentials in their memory space or context window. Instead, the agent runtime interacts with a Credential Broker: The agent requests a specific action via a scoped tool interface. The Policy Engine validates the request. The Credential Broker mints an ephemeral, single-use, time-bound credential (such as an AWS STS assumed role or a short-lived JWT) and injects it directly into the downstream network call. The raw credential never touches the agent context or the model's memory. Sandboxing Code and Browser Execution When agents write code, execute scripts, or automate web browsers, execution must occur inside hardened, ephemeral sandboxes: Filesystem Boundaries: Rootless container namespaces with read-only root filesystems and ephemeral scratch spaces. Network Restrictions: Egress traffic filtered through strict Layer 7 firewalls and domain allowlists. Resource Limits: Strict cgroups enforcement capping CPU time, memory allocation, and execution timeouts (e.g., maximum 30 seconds per execution). Tenant Isolation in Enterprise AI Multi-tenant agent systems must prevent cross-tenant data leakage. If an agent executes a search query across a vector database, the query parameters must be programmatically injected with tenant-scoping filters at the database driver layer, ensuring that model-generated query text cannot omit tenant identifiers. 8. Auditability and Immutable Logging Because autonomous agents execute non-deterministic, multi-step workflows, post-incident forensic analysis requires an immutable, cryptographically verifiable audit trail. Every agent interaction must record an audit event capturing the complete chain of custody: { "timestamp": "2026-03-30T14:22:10.104Z", "session_id": "sess_99f8a1c3e", "user_id": "usr_77a2b", "agent_id": "agnt_support_v2", "task_id": "tsk_44d9b", "tool_name": "query_customer_ledger", "requested_action": "read", "resource_identifier": "tenant_acme_corp:ledger_2026", "authorization_decision": "ALLOW", "policy_id": "pol_tenant_read_v1", "execution_result": "success", "hash_signature": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" } Enter fullscreen mode Exit fullscreen mode This structured event schema ensures that security operations teams can reconstruct the exact path from human user to agent runtime, policy evaluation, tool invocation, and resource modification without relying on opaque LLM logs. 9. Technical FAQ How should AI agent permissions be designed? AI agent permissions should be designed using capability-based access control, dynamic policy engines (such as Open Policy Agent or AWS Cedar), and short-lived, scoped credentials brokered at the tool execution boundary rather than granting the model broad service account access. What is least privilege for AI agents? Least privilege for AI agents restricts tool access, database queries, and cloud resource interactions to the absolute minimum capabilities required to complete a specific task for a verified human user, avoiding static, highly privileged API keys. Should AI agents have their own identity? Yes. Autonomous agents require distinct service identities separate from the end-user. This enables traceability in audit logs while ensuring that policy engines can evaluate both the user's entitlements and the agent's runtime execution scope. How do you prevent an AI agent from accessing sensitive data? Sensitive data access is prevented by interposing a centralized policy engine between the agent's tool calls and the data layer, enforcing tenant-scoping filters, read-only constraints, and preventing raw credentials from entering the model's context window. Can prompt injection bypass AI agent permissions? Prompt injection can alter model behavior and intent, but it cannot bypass properly implemented system enforcement layers. If authorization checks, credential brokers, and policy engines operate independently of model output, an injected prompt remains bounded by the user's strict access permissions. Originally published at WantsVibes. Explore in-depth systems architecture breakdowns, distributed systems guides, and AI engineering benchmarks on WantsVibes.online.