Layer 1 — Security Foundations
Everything an agent does eventually resolves to a network call made by a process running as some identity against some resource. If you cannot reason about that sentence — the packet, the process, the identity, the resource — you cannot reason about agent security. This layer is classical security, but the emphasis is different from a traditional appsec curriculum: identity and cryptography carry disproportionate weight, because an agent is a non-deterministic component that holds delegated authority and talks to other components across trust boundaries.
The six areas, and why each matters for agents
| Area | Generic reason | Agentic reason |
|---|---|---|
| Networking | Understand traffic, segmentation, DNS | Egress is the exfiltration path. An agent that can reach arbitrary hosts can be steered into sending your data anywhere by a single poisoned document |
| Linux | Operate and harden hosts | Agents execute code. Process isolation, namespaces, capabilities, and file permissions are what stand between “run a script” and “read every secret on the box” |
| IAM | Least privilege, RBAC | The load-bearing skill. Agent identity, delegated authority, and token scope decide whether a prompt injection is an annoyance or a breach |
| Cloud security | Configure AWS/Azure/GCP safely | Agents are deployed as serverless functions and containers with attached roles. The role is the blast radius |
| Threat modeling | Find design flaws early | Non-determinism means you cannot enumerate behaviors by testing. Structured modeling is the only systematic coverage you get |
| Cryptography | Confidentiality and integrity | Signed tool manifests, verified model artifacts, mTLS between services. Every trust boundary between agents is ultimately a key |
IAM is the one to over-invest in
An agent’s most dangerous property is not that it can be tricked. It is that when it is tricked, it acts with credentials someone gave it on purpose. The severity of nearly every serious agentic incident pattern traces back to an over-scoped identity: a role with * on a data store, a service account shared across agents, a token whose lifetime outlives the task, or a human’s OAuth grant silently reused by an autonomous process at 3am.
Things you should be able to do without looking them up:
- Explain the difference between authentication, authorization, and delegation, and say which one an agent’s tool call exercises.
- Read an AWS IAM policy document and state exactly what it permits, including what
Resource: "*"combined with a condition key actually means. - Explain OAuth 2.0 authorization code flow, what a refresh token is, and why a long-lived refresh token in an agent’s memory store is a durable compromise.
- Describe workload identity federation (or the equivalent on your cloud) and why it beats a static key in an environment variable.
- Design a scheme where an agent acts on behalf of a specific user, and the downstream service can tell which user, not just which agent.
That last point is the one to be able to argue in an interview. See what employers screen for for how this question tends to be asked.
Cryptography as the root of inter-agent trust
Cryptography is usually taught as a menu of primitives. For this field, learn it as a set of answers to trust questions between components that do not fully trust each other.
| Question | Mechanism | Where it shows up in agentic systems |
|---|---|---|
| Is this channel private and authentic? | TLS, and mTLS when both ends must prove identity | Agent-to-tool-server links, MCP servers over the network, internal service mesh |
| Is this artifact the one the author published? | Digital signatures, checksums over signed manifests | Model weights, container images, tool/plugin manifests, MCP server packages |
| Who holds the keys, and can I revoke them? | KMS/HSM, key rotation, envelope encryption | Encrypting agent memory stores, conversation logs, retrieved documents at rest |
| Can I prove this log was not altered? | Hash chains, append-only logs, signed timestamps | Audit trails for agent actions — the evidence you hand an auditor |
| Can I reference sensitive content without storing it? | Cryptographic hashing | Prompt hashes and argument digests in telemetry, so traces are useful without leaking payloads |
You do not need to implement primitives. You need to be able to say, precisely, what property a given control gives you and what it does not. “We sign our tool manifests” gives you integrity and authorship, not confidentiality, and it gives you nothing at all if nobody verifies the signature at load time.
Trust boundary checklist (say all four for every arrow in your diagram)
1. Who is on each end, and how is that proven?
2. What is the channel, and is it authenticated in both directions?
3. What is the payload, and is its integrity verified before use?
4. What is logged, and can the log be tampered with after the fact?Threat modeling: STRIDE and PASTA
Learn STRIDE first because it is fast, per-component, and gives you a vocabulary. Learn PASTA second because it is risk-centric and attacker-simulation driven, which is what you want when you have to justify prioritization to a business audience rather than just enumerate flaws.
Practical split: STRIDE for the design review of a specific agent, PASTA when you are asked “what should we actually fix first, and why that order?”
STRIDE applied to an agent — worked example
Model the target as: a planner LLM, a tool executor, an MCP tool server, a vector store, and an outbound API the agent can call.
| STRIDE category | What it looks like for an agent | Control to reach for |
|---|---|---|
| Spoofing | A rogue MCP server registers under a trusted tool name; an attacker impersonates the orchestrator to the tool executor; retrieved content claims to be a system instruction | mTLS between agent and tool servers, signed tool manifests, strict separation of instruction and data channels |
| Tampering | A poisoned document in the vector store rewrites the agent’s plan; tool arguments are modified between planning and execution; memory entries are edited to persist an instruction | Integrity checks on ingested content, source allowlists, immutable plan-to-execution handoff, signed memory writes |
| Repudiation | Nobody can say which agent instance called the payment API, under whose authority, or which prompt produced the call | Correlated traces with prompt hash, tool name, argument digest, actor identity; append-only audit log |
| Information disclosure | Secrets pulled into context and echoed in output; the agent is steered into fetching a URL with data in the query string; retrieved documents leak across tenants | Egress allowlist, output filtering, per-tenant retrieval scoping, secrets never placed in context |
| Denial of service | Recursive planning loops burning tokens and budget; an injected instruction that makes the agent retry forever; one tenant starving a shared tool server | Step and token budgets, loop detection, per-identity rate limits, circuit breakers on tool calls |
| Elevation of privilege | The agent uses a broad role to reach a resource the requesting user cannot access; chained tool calls compose into an action neither tool authorized alone | Per-request delegated credentials, authorization checked at the tool boundary rather than in the prompt, human approval gates on high-impact actions |
Build this table for a system you actually wrote — Lab 5 walks through turning it into a risk register, and OWASP Agentic Threats gives you the named-threat vocabulary to attach to each row.
Networking, Linux, and cloud: the specific slices to learn
The generic curricula for these are enormous. These are the slices that come up constantly in agentic work.
| Area | Learn deeply | Learn to recognize | Skip for now |
|---|---|---|---|
| Networking | Egress control, DNS resolution paths, proxies and TLS interception, service-to-service auth | Load balancers, service mesh basics, VPC peering | Routing protocols, deep packet internals |
| Linux | Users and permissions, namespaces and cgroups, capabilities, seccomp, process isolation, /proc exposure | systemd units, syscall tracing tools | Kernel development, custom LSM authoring |
| Cloud | Identity and role assumption, resource policies, secrets managers, KMS, network egress from serverless and container workloads, audit logging (CloudTrail and equivalents) | Managed AI service configuration, private endpoints | Multi-cloud parity trivia, exam-only service coverage |
One provider deeply beats three shallowly. The concepts transfer; the console screens do not, and nobody hires on console screens. Pick the cloud your target employers run — core roles gives a sense of which that tends to be per role type.
Security architecture in one paragraph
Architecture skill here means being able to draw the system, mark every trust boundary, and name the control at each crossing — then defend the choice of control against “why not just prompt it not to do that?” The answer you should have ready: prompt instructions are advisory, and the model is the component the attacker controls the input to. Controls that matter live outside the model — in the network policy, the credential scope, the tool schema validation, and the approval gate.
How to study this coming from software engineering
You already have the mental models for state, protocols, and failure. The gap is usually adversarial framing and identity depth.
| If you already know | Your gap is usually | Fastest way to close it |
|---|---|---|
| HTTP, APIs, and TLS as a config flag | Certificate chains, mTLS, what verification actually checks | Stand up a two-service mTLS setup by hand, then break it deliberately: wrong CA, expired cert, hostname mismatch |
| Docker and cloud deploys | The identity attached to your workload, and its exact scope | Take one service you own and enumerate every permission its role grants. Cut it until something breaks, then add back only that |
| Writing tests | Thinking about what an attacker wants, not what a user does | Write abuse cases next to your test cases: for each feature, one sentence on how it is misused |
| Reading logs to debug | Logging as evidence with integrity requirements | Ask of your logs: could a compromised process erase its own tracks? |
| “Encryption is on” | Which property you actually bought | For each crypto control in your stack, write one line: integrity, confidentiality, authenticity, or non-repudiation |
Sequence that works: IAM → networking/egress → Linux isolation → cryptography as trust plumbing → threat modeling as the synthesis step. Threat modeling last, because it is only as good as your knowledge of the controls you can propose. Then apply all of it to something you built — Month 1 of the 90-day plan is structured this way.
Self-check
Answer out loud, in full sentences. If you stall, that is your study list.
- I can draw a trust boundary diagram for an agent system and name the control at every crossing.
- I can read an IAM policy and state its blast radius, including the conditions.
- I can explain how an agent acts on behalf of a user without becoming a shared super-identity.
- I can describe what mTLS proves that TLS alone does not.
- I can explain why signing a tool manifest is worthless without verification at load time.
- I can run STRIDE over an agent design and produce at least two threats per category.
- I can explain when PASTA earns its extra weight over STRIDE.
- I can name three ways an agent’s egress path becomes an exfiltration channel.
- I can explain what a compromised process could do to my audit logs, and what would prevent it.
- I can argue why a prompt instruction is not a security control, without sounding dismissive of prompt design.
Next: Layer 2 — Engineering Craft, where these controls stop being diagrams and start being code, containers, and telemetry.