LLM and Autonomous Agent Security

C H A P T E R 0 4 Separate workflow decisions from untrusted values Some tasks have a stable structure: retrieve a record, compute a summary, show a draft. Others require the agent to explore and revise its plan. Choose controls that match that difference. If the task is already known, representing it as an explicit workflow can remove unnecessary model discretion. If the task is open-ended, bounded capabilities and checkpoints matter more than pretending the plan will never change. CaMeL demonstrates a design that separates control flow from untrusted data and applies capability- based checks to data flows. Its security argument depends on the interpreter, policies and assumptions in the construction. It is evidence for a valuable architectural pattern, not a universal guarantee for any application that uses two models or a “planner” prompt. [S03] A concrete workflow contract Suppose a user requests an internal summary of invoices from an approved account. The contract names the account, allowed sources, output audience, expiry and maximum work. A retrieval tool returns typed invoice records. A summarizer produces a candidate summary. A delivery service checks that the destination remains internal and authorized. If the model proposes paying an invoice, that operation falls outside the contract. FIGURE 03 / DATA-FLOW POLICY Constrain the path from source to sink Source label Tenant A · invoice data · restricted Task grant Summarize account A · internal audience ↓ Transformation preserves provenance ↓ Transform Summary inherits the relevant restrictions Sink check Recipient and channel satisfy the grant Only a reviewed release operation may relax a data restriction. Labels describe information constraints; an authorization check still decides whether this particular action is allowed. LLM & Agent Security SECURITY FIELD GUIDES aisecurityinterviews.com / field guides 10

C H A P T E R 0 7 Secure MCP as a protocol and a software supply chain MCP standardizes how a client discovers and calls capabilities. It does not make every server, tool description or result trustworthy. A remote server can be properly authenticated and still return misleading content. A local server is executable software with the privileges of its runtime. Review both the protocol boundary and the implementation that handles it. Pin the protocol revision in a design review. The July 28, 2026 revision differs from older session- oriented deployments. Do not carry assumptions about initialization, sessions or task mechanisms across revisions without checking the applicable specification and extension set. The authorization material cited here is revision-specific; interoperability testing must include the versions actually deployed. [S05] [S16] Four reviews for every server First, review provenance: package or image digest, source owner, build evidence and update channel. Second, review authority: runtime identity, accessible data, filesystem, network and downstream credentials. Third, review interface: tool names, schemas, descriptions and annotations. Fourth, review behavior: actual calls, unexpected destinations, persistent state and failure handling. FIGURE 05 / SERVER ADMISSION A registry entry is the start of the review Artifact Pinned implementation and build evidence Interface Reviewed tool schema and description digest ↓ Recheck the changed layer ↓ Runtime Bounded identity, filesystem and network Request User/task policy and destination checks A familiar server name does not authorize a changed implementation or tool. Admission evidence and per-request authorization answer different questions. Keep both. LLM & Agent Security SECURITY FIELD GUIDES aisecurityinterviews.com / field guides 16

C H A P T E R 1 5 Bind approval to the exact action Human approval is useful only when the person can understand and control the effect being approved. A friendly summary produced by the same model proposing the action may omit critical fields. Build the approval view from the normalized operation that the executor will use, and present the fields that materially change risk: target, destination, content, amount, permissions and affected resources. Approval is a grant with scope and expiry. It is not a general statement that the agent may continue doing whatever seems useful. If the destination or payload changes, compare the new operation against the approved operation and obtain fresh authorization when the change falls outside the grant. Prepare, approve, commit First prepare a canonical operation and a digest over its meaningful fields. Then show a trusted preview and record the approving principal, digest, expiry and relevant resource version. Finally, at commit, check authorization again, recompute the digest, verify the resource version and consume the grant under the same transactional rules as the effect. FIGURE 12 / APPROVAL BINDING The preview and the effect name the same operation Prepare Normalize recipient, payload and resource version Review Trusted preview; approving principal and expiry ↓ Reject material drift before execution ↓ Commit gate Digest match, current rights and unchanged state Receipt One operation key and authoritative result Approval covers these fields on this resource, not an unbounded next step. Hash binding detects changes only when the canonical operation includes every field that matters. LLM & Agent Security SECURITY FIELD GUIDES aisecurityinterviews.com / field guides 32