AI Security Architecture explains the system-level design: where trust boundaries sit, and which parts of a system need their own checks. This lesson is about the concrete engineering controls that actually implement that design — the specific validation, authorization, and handling logic a team writes.

Input validation

Checking incoming requests — format, length, disallowed content — before they reach the model, catching obviously malformed or malicious input early.

Output validation

Checking a model's response — and any tool call it requests — against expected format and policy before it's used or shown.

Authorization and least privilege

Ensuring a request only accesses data and tools the requesting user or agent is actually permitted to use — enforced by application code, not by asking the model nicely.

Secrets handling

Keeping API keys and credentials out of prompts entirely — they belong in the application or gateway layer, never constructed into text a model reads.

Data isolation

Filtering retrieval and storage by tenant or user, enforced at the query level — the same concern covered architecturally in multi-tenant AI architecture.

Audit logging

Recording what was accessed, what tools were called, and by whom, so an incident can actually be investigated after the fact.

Illustrative pseudocode for a tool-call authorization check:

def authorize_tool_call(user, tool_name, arguments):
    if tool_name not in ALLOWED_TOOLS_FOR_ROLE[user.role]:
        raise PermissionDenied(f"{user.role} cannot use {tool_name}")

    if tool_name in SENSITIVE_TOOLS:
        require_human_approval(user, tool_name, arguments)

    audit_log(user, tool_name, arguments)
    return True

• Relying on the system prompt as the only defense

  Prompt instructions influence behavior but are not a reliable enforcement mechanism against adversarial or malformed input.

• Authorizing at the wrong layer

  Checking permissions only in the UI, and not again in the backend or at the tool-execution layer, leaves a gap an attacker can bypass.

• Embedding secrets into prompts or tool schemas

  Any credential a model can read is a credential that could leak through model output.

• No audit trail for tool calls or data access

  Without one, investigating what actually happened during an incident becomes guesswork.

• Validating input but not output

  A model can produce unsafe or policy-violating output even from a fully validated, reasonable input.

• Treating security as a one-time setup rather than continuous enforcement

  New tools, new data sources, and new agent capabilities each need their own security review as the system evolves.