Naveo

STEP 10 / 20

D3 WIRING

WIRE SOURCES → TARGETS

Your system has several components. Each one produces data another consumes. The question isn't "who's good and who's bad?". the question is where do you stop trusting and start validating?

There are six components that emit data. Three destinations that receive it. Wire each emitter to the destination where you can send its output directly, without additional validation. If you'd have to validate before sending, it's NOT a valid wire in this exercise.

SOURCES

Internal app config

Lives in your repo, controlled by code review.

Vault-resolved secret

Your vault returned the real API key.

User message

Free text from the frontend. Can be anything.

External tool response

The model called a third-party API. it returned text.

LLM output

The model returned an answer for the user.

RAG document

Fragment of a page, PDF, transcript, indexed in your vector store.

TARGETS

Model context (untagged)

You drop it directly into the prompt with no tags or separation.

Tool call (trusted side)

The tool runs on your trusted infrastructure.

User's screen

Goes straight to the UI with no additional filters.

GUEST MODE

You're viewing this lesson as a guest. To save your progress, earn XP, and keep your streak, sign in when you're ready to check.

Costs 1 heart

Where do you stop trusting?

The most important architectural question in AI security is where is the trust boundary?. Not "I trust X" / "I don't trust Y". that's binary and false. The real question is: at what point in the flow do you stop treating data as trusted and start treating it as input that needs validation?

The mental rule

Tag every data source:

Trusted. You control the code that produces it. Repo, code review, deploy, your infrastructure.
Untrusted. Anything that crossed a network boundary, came from a user, was generated by the model, was read from an external document, or passed through a third-party API.

Trusted can drop in directly. Untrusted must be tagged and validated before crossing to another layer.

The four untrusted sources in the exercise

User message. Obvious. the user can type anything, including payloads. Must enter the model inside <user_input> tags, after sanitization (length, Unicode, PII scrubbing).

LLM output. Less obvious, but equally important. The model's output is untrusted because the model may have been injected. Any output going to a destination with power (destructive tools, user screen, next agent step) must pass output validation (lesson 15).

External tool response. You hit a third-party API. that response is text from the world, may have a hidden payload. Wrap in <tool_output> and declare it as data, not instruction.

RAG document. Your vector store returned a fragment. that fragment was written months ago, in a different context, possibly by someone hostile. Same treatment: <retrieved_content>, data not instruction.

The two trusted ones

Internal config. Lives in your repo. If it changed, there was a PR, there was a review. That's the only reason you trust it.

Vault secret. Trusted in content (you put it there, encrypted, audit-logged). But its safe destination is only the tool on the trusted side. Never to model context, never to the user screen.

Hex's rule: when you draw the architecture, color the arrows. Green = trusted. Red = untrusted. Every red arrow needs a validation layer before crossing to a powerful destination. If you can't point at that layer, the layer isn't there.

On the right: six emitters, three destinations. Wire only the green arrows.