Layer 5 — Communication & Influence
The characteristic failure of technical people in this field is being right and ignored. You find a real flaw in an agentic system, you write it up accurately, and nothing happens — because the write-up asked a decision-maker to do work you should have done for them. This layer is the skill of making a finding decidable: what could happen, how bad, how likely, what it costs to fix, and what you recommend. It is learnable, it is mostly writing, and it compounds faster than any technical skill on this site.
The three competencies
| Competency | What it means here | The test |
|---|---|---|
| Risk communication | Translating agent behavior into consequence, quantity, and a decision | An executive reads one page and knows what to approve |
| Policy documentation | Writing the artifacts that make an AI system governable — acceptable use policies, model cards, system cards | Someone follows your document without asking you a question |
| Cross-team translation | Carrying the same fact across legal, compliance, product, and ML without distorting it | Four teams leave the meeting with the same understanding |
Same finding, written badly and written well
The technical content below is identical. Only one gets fixed.
Badly
The customer-support agent is vulnerable to indirect prompt injection. Untrusted content retrieved from the knowledge base is concatenated into the system context without provenance separation, so an attacker-authored document can influence the planner’s tool selection. The agent’s execution role has broad read access to the ticketing backend, and egress is unrestricted. This is OWASP LLM01 combined with excessive agency. Recommend implementing provenance labeling, tightening the IAM role, and adding an egress allowlist.
Everything in that paragraph is true. It still fails, because the reader cannot tell whether this is urgent, what it would cost them, or what they are being asked to decide. It uses a framework identifier as a substitute for impact, and it hands over three tasks with no priority. The implicit ask is “go understand my domain and then decide” — which is exactly the work that does not get done.
Well
Finding: A customer can cause our support agent to read other customers’ tickets.
How: The agent trusts the text of any document it retrieves. Anyone who can get content into the knowledge base — including through a submitted support ticket — can insert instructions the agent will follow. Because the agent’s credentials grant read access across all tickets rather than only the requesting customer’s, a successful attempt returns other customers’ data. Nothing in the current setup restricts where the agent can send that data.
Exposure: All tickets reachable by the agent’s role, across every customer account. Any of the ingestion paths that write into the knowledge base is a viable entry point.
Likelihood: No specialized skill required — this is text in a document, not an exploit. We have no detection for it today, so we cannot say whether it has been attempted.
Fix, in order: (1) Restrict the agent’s credentials to the requesting customer’s tickets — roughly one sprint, no product change visible to customers. (2) Restrict where the agent can send data to an approved list — days. (3) Separate trusted instructions from retrieved content — larger, and (1) removes most of the impact without it.
Ask: Approve (1) and (2) this cycle. (3) goes on the roadmap.
What changed: consequence in the first sentence, in the reader’s own terms; mechanism in plain language without jargon; exposure stated as scope rather than a severity label; likelihood expressed as attacker effort with an honest note about what is unknown; remediation ordered by impact-per-cost; and a single, specific ask. Framework identifiers still belong in the report — in an appendix table, where they help the security team aggregate and do not stand in for meaning.
Quantifying without inventing numbers
Executives ask for numbers. The temptation is to produce a false one — a made-up probability, a borrowed industry average, a severity score presented as though it were measurement. Do not. Fabricated precision is discovered eventually, and it costs you the credibility that made you useful. There are honest alternatives.
| Technique | What you say | Why it holds up |
|---|---|---|
| Exposure surface counts | “The agent’s role can read N ticket records across M customer accounts.” | It is a count of things you can verify, not a prediction |
| Ranges with stated bounds | “Between one and four weeks of engineering, depending on whether the auth change touches the mobile client.” | Honest uncertainty is more credible than a fake point estimate |
| Attacker-effort framing | “This requires typing text into a form, not writing an exploit.” | Replaces probability with a difficulty statement you can defend |
| Comparable-incident framing | “This is the same failure shape as a broken object-level authorization bug in a REST API — we treat those as high.” | Anchors to a class the organization already knows how to price |
| Conditional statements | “If the agent’s role were scoped per-customer, this finding would be an information leak of a single account rather than all accounts.” | Shows exactly what the control buys |
| Detection gaps as facts | “We currently have no telemetry that would show this occurring.” | An honest unknown, stated as a finding in its own right |
| Reversibility | “This action cannot be undone once the agent executes it.” | Impact dimension that needs no statistics at all |
Exposure counts are also where Layer 2 pays off directly: telemetry that records which tool was called on whose authority is what lets you say “N times last month” instead of “potentially.”
One-page finding memo template
One page. If it runs to two, the second page is an appendix.
TITLE: <consequence in plain language, no jargon, one line>
FINDING 1-2 sentences. What can happen, to whom.
MECHANISM 3-5 sentences. How it works, in words a PM understands.
EXPOSURE What is reachable. Counts and scope, not adjectives.
LIKELIHOOD Attacker effort + preconditions + what we cannot observe.
EVIDENCE Repro steps, trace ID, or screenshot. Link, do not embed.
OPTIONS 2-3 remediation options, each with cost and residual risk.
RECOMMEND One option. Say which, and why that one.
ASK The specific decision, the owner, and the date.
APPENDIX Framework mappings, full technical detail, raw traces.Rules that make the template work: the title is a consequence and never a vulnerability class; EXPOSURE contains numbers you can verify; OPTIONS always includes accepting the risk, described accurately, because pretending it is not an option costs you the reader’s trust; ASK names one person, not a team.
Policy documentation
| Artifact | Answers | Written for | Failure mode |
|---|---|---|---|
| Acceptable use policy | What may this agent be used for, and what is prohibited? | Every employee who touches it | Written so abstractly that nobody can tell whether their use case is allowed |
| Model card | What is this model, what data, what limits, what evaluations? | Engineers, reviewers, auditors | Marketing copy with a limitations section that admits nothing |
| System card | How does the deployed system behave — tools, autonomy level, human oversight, safeguards? | Reviewers, customers, regulators | Describes the intended design rather than what actually shipped |
| Agent registry entry | Which agents exist, who owns them, what can they reach? | Security, compliance, ops | Maintained by hand, and stale within a quarter |
For agentic systems the system card is the one that carries the most weight, because the interesting properties are not in the model. They are in what the agent may do without asking, which tools it holds, where it can send data, and who is accountable when it acts. Write it against the shipped configuration and regenerate it from the configuration where you can — that is the discipline in evidence automation, and the obligations behind it come from the EU AI Act and ISO/IEC 42001.
Cross-team translation
The same fact, four audiences. Distorting it to please any of them is how you lose the room later.
| Audience | Cares about | Speak in | Never |
|---|---|---|---|
| Legal | Obligation, liability, jurisdiction, disclosure duty | Concrete facts and dates; what the system does, not what it might do | Speculate about legal exposure |
| Compliance | Control existence, evidence, auditability, mapping | Controls, owners, evidence artifacts | Say “we handle that” without pointing at the artifact |
| Product | Users affected, roadmap cost, degradation of experience | Scope, effort ranges, alternatives, sequencing | Present security as a binary block |
| ML / research | Model behavior, evaluation methodology, false positive cost | Reproductions, datasets, measurable criteria | Hand-wave the technical mechanism |
The translation skill is holding the underlying fact constant while changing the frame. If your version for product is materially softer than your version for compliance, you are not translating — you are managing perception, and the day those two audiences compare notes, you are the problem.
The failure mode: being right and ignored
It is worth naming precisely, because it is the default outcome for talented people entering this field.
| Pattern | What it looks like | The correction |
|---|---|---|
| Severity as argument | “This is critical” repeated louder | Consequence, exposure, and cost of fixing |
| Framework as authority | “This violates LLM01” | Say what happens to a customer; put the identifier in the appendix |
| No ask | A thorough report with no decision requested | One named owner, one decision, one date |
| All-or-nothing | Full redesign or nothing | Sequenced options, cheapest impact reduction first |
| Volume | Forty findings of undifferentiated weight | Top three with an appendix; ranking is the work |
| Purity | Refusing to acknowledge business trade-offs | Present risk acceptance as a legitimate, documented option |
| Absent until incident | Silence, then “I flagged this months ago” | Circulate the register on a cadence, with an owner per row |
Practice loop
Every technical artifact you produce gets a one-page memo written for a non-technical reader. Every lab on this site is a chance to practice: the finding table is the technical output, the memo is the one that gets it fixed. Have someone outside security read the memo and tell you what they think you are asking for — if their answer differs from your intent, revise the memo, not the reader. Over a quarter this produces a portfolio of writing that is more differentiating than the code, because far fewer people have it. See portfolio to offer for how these artifacts get used in a hiring process, and choosing your path for the roles where this layer becomes the primary job rather than a supporting one.