Mr.PlanB Logo

    AI Security

    You run where the model runs.

    Most AI security writing is aimed at the people building the model or the app. This section is for the people who provision the nodes it runs on, set its quotas, decide what it can reach on the network, and keep the log that proves what it did. That is a different job with different controls, and it is under-served.

    The line this section draws

    The Cloud Security Alliance's MAESTRO threat model splits an AI system into seven layers. That split is useful here because it puts a clean line through the stack, and infrastructure work sits almost entirely on one side of it.

    The tenant owns what the model does. You own where it runs, what it can reach, and whether anyone can see it happening.

    It is the cloud shared-responsibility model applied to AI, which means the shape is already familiar. It also means an honest answer to "so does this stop prompt injection?" — no, that lives on layers 3 and 7, and pretending otherwise is how teams end up buying the wrong thing.

    • 7Agent ecosystemMarketplaces, inter-agent protocolsTenant
    • 6Security and complianceYou supply the evidence, the tenant sets the policyShared
    • 5Evaluation and observabilityTelemetry, job monitoring, anomalies in resource useOperator
    • 4Deployment and infrastructureSandboxing, tenant isolation, segmentation, GPU schedulingOperator
    • 3Agent frameworksAn integration point, not your codeTenant
    • 2Data operationsYou secure storage and the registry, the tenant owns pipelines and RAGShared
    • 1Foundation modelsYou secure the registry that serves themTenant

    Layers 4 and 5 are entirely yours. Layers 2 and 6 are shared. The rest are covered here for context and never claimed.

    A request flows left to right through a terminal, a gateway and a language model, then crosses a vertical boundary plane to reach a gear, a database and a cloud, and finally a storage stack. Everything before the boundary is amber; everything after it is blue.
    The same line, in a request path. Everything left of the boundary is text — a prompt, a retrieved document, a tool result — and any of it may be hostile. Everything right of it holds a credential. The model cannot be relied on to keep them apart, so the boundary has to be somewhere it does not decide.
    Tenant sideOperator side

    Two problems, one name

    “AI security” gets used for two jobs that share almost nothing. One is protecting a system you built or run, where the adversary is whoever can get text in front of your model. The other is defending against an attacker who has a model of their own, where nothing in your architecture changes what they can do.

    Different owners, different controls, different budgets. Most of this section is about the first. The Weaponized AI track is about the second, and it is here because teams that conflate the two buy the wrong thing.

    Split composition. On the left, a server rack inside a glowing shield with three arrows curving inward toward it. On the right, an envelope with three arrows radiating outward toward three human figures.
    Left: securing AI. Your infrastructure, your credentials, attacks arriving at what you run. Right: AI as the weapon. Their model, your staff, and an inbox. A gateway inspecting your assistant’s prompts does nothing about the second; mail filtering does nothing about the first.

    The series

    0 of 20 published

    Twenty articles in four tracks, publishing in the order below. Pieces marked Operator are the ones that read directly to someone who runs the infrastructure; start there if you only read a few.

    A

    Foundations

    How do we even think about AI risk?

    1. A3Securing AI and defending against it are two different problemsOperator
    2. A2Seven AI security frameworks, and which one you actually need
    3. A1Your threat model was written for software that behaves the same way twice
    B

    Securing LLM applications

    How do we protect a system that uses a model?

    1. B2Excessive Agency is a permissions problem wearing an AI costumeOperator
    2. B1Prompt injection is not a bug you patch, it is a property you design around
    3. B6The AI gateway pattern: what it should do, and what it can'tOperator
    4. B3Sensitive information disclosure: your model is a new exfiltration channel
    5. B4Hidden context exposure: everything the user can't see is still attackable
    6. B5Unbounded consumption: denial-of-wallet is the new denial-of-serviceOperator
    C

    Securing agents and MCP

    What changes when the model can act?

    1. C1Assistant vs. agent: the line that changes your security model
    2. C3MCP is the USB-C of AI agents, and USB was an attack surface too
    3. C2The OWASP Agentic Top 10, read as an attack chain
    4. C6Five questions to ask before an agent touches productionOperator
    5. C4Using third-party MCP servers safely: a minimum standard
    6. C7Threat modeling an agent with MAESTRO: a worked exampleOperator
    7. C5Building an MCP server: you're writing a privileged API with a non-deterministic caller
    D

    Weaponized AI

    What happens when the attacker has the model?

    1. D1Every phishing marker you trained people on is gone
    2. D3Zero Trust against AI-driven social engineering: identity and process, not the network
    3. D2Mass-produced personalization: why phishing volume fell while losses tripled
    4. D4AI on the message: what a model can see that a filter can't

    The infrastructure these risks land on is already covered here. These are the guides the series will build on:

    Every article here names the edition of any framework it cites and carries the date its sources were last checked. Frameworks in this area revise yearly, and an undated claim about them stops being true without telling you.