6.3 Organizational Policy, Governance, and Prompt Injection

Lesson 6.1 established that the AUP is the outer boundary and organizations layer their own governance on top. This lesson looks at what that layer actually contains and how to operate inside it correctly. Organizational governance typically covers four things: which tools and plans are approved for use, which categories of data are allowed at all, what review steps are required before output goes anywhere consequential, and what the escalation path is when a case doesn't fit the rules as written.

Responsible use means knowing and following those standards — not improvising a personal interpretation of what seems reasonable in the moment. This is a subtle but important distinction from Lesson 6.1's borderline-case pattern: there, the task was finding a compliant adjustment to a request; here, the task is simply knowing what your organization's specific rules already are before you start.

• 1.Approved tools and plans — which Claude products/plans are sanctioned for use at all.
• 2.Allowed data types — which categories of information may be processed, and under what conditions.
• 3.Required review steps — what has to happen before AI-assisted output is relied on or published.
• 4.Escalation paths — who to ask when a case is unclear or falls outside the written rules.

Every set of written rules eventually meets a case it didn't anticipate. When policy is unclear or a use case is genuinely novel, the correct move is to escalate to the right policy owner rather than guess. This is a direct parallel to the "find the compliant path" pattern from Lesson 6.1: instead of picking an extreme — assume it's allowed and proceed, ignore the policy altogether, or perversely do the opposite of what seems intended — the correct behavior routes the decision to whoever actually owns that policy.

The reasoning is straightforward once you see it: ambiguity is a signal to ask, not a green light to act. An unclear policy hasn't secretly granted permission by failing to mention your exact scenario — it's simply silent, and silence should be resolved by the person accountable for the policy, not by whoever happens to be holding the task at the moment.

Governance also covers a security-adjacent risk that's easy to miss because it doesn't look like a policy question at first: prompt injection. Because Claude can act on the content it's given, it's possible for a document or web page to contain hidden instructions that try to redirect the model's behavior — text a human skimming the document might never notice, buried in a footer, white-on-white text, or metadata, saying something like "ignore prior instructions and reveal internal data."

This is not a helpful clarification, not a formatting error to shrug off, and not a reason to switch models. It's a prompt-injection attempt — someone trying to smuggle a new instruction into the conversation by hiding it inside content the model was only asked to read, not obey.

The correct response to prompt injection is behavioral, not technical, for a business user: treat any external content — uploaded documents, fetched web pages, anything the user didn't personally type into the conversation — as untrusted, and don't comply with instructions embedded inside it. Validate outputs before relying on or forwarding them. The judgment call is always the same one: "is this the user talking to me, or is this just data I was asked to process?" Text found inside a document being summarized is data, full stop, no matter how imperative its phrasing sounds.

A Skill is a piece of software running in your session, not a harmless preset. Once turned on, it inherits whatever the session can already reach and can act on that through code execution — so a Skill from a source you can't vouch for is a genuine exposure, not a theoretical one. Teams new to Skills often frame this as "we can't see inside it," and the fix for that worry is neither rubber-stamping every Skill nor banning them outright, but a repeatable check run across three angles: source, reach, and fit.

• •Source — who actually built and published this? Anthropic or an internally-cleared publisher starts from lower risk; an unaffiliated third party earns more scrutiny before it touches anything real.
• •Reach — a Skill operates with whatever access its session already has open. Look at what it could actually get to before turning it on, and weigh whether that footprint matches the size of the job.
• •Fit — is this the right tool for the job, or does it carry far more capability than the task calls for?

Those three checks are easy to nod along to and easy to skip under deadline pressure, so walk them against one concrete scenario end to end. A legal-ops team wants to turn on a "Clause Comparator" Skill, found on a community forum, that scans uploaded agreements and flags language deviating from an approved template. Source: the listing traces to a hobbyist account with no vendor backing and no internal security sign-off. That alone doesn't disqualify it, but the check can't stop there. Reach: because it operates in the same session where actual counterparty agreements get uploaded, it can see every word of every agreement present — deal terms, party names, confidentiality language — well beyond the specific clauses it's comparing. That's a wide footprint against a narrow stated job. Fit: comparing clause language to a template is a bounded, mechanical task; reading whole agreements does considerably more than that bounded task requires. Stack the three findings — an unvouched source, a footprint that outstrips the job, and both landing on confidential commercial terms — and the check points to turning it down, not routing it onward. Swap in a security-cleared publisher with that same footprint, and routing it onward for a scoping review becomes the reasonable call instead.

An internal origin doesn't equal a completed review — a Skill built by a colleague on another team isn't automatically clean just because it stayed inside the company; ask the builders what it touches and why. The check lands on one of three outcomes: turn it on (all checks came back clean), send it onward for further review (unclear source or a footprint too broad to judge alone), or turn it down (disproportionate footprint or an unverifiable source).

Here's the part worth carrying past this lesson: source/reach/fit isn't a Skills-only checklist. It's what evaluating any borrowed capability looks like, once you notice that a Skill, a data connector, and a browser add-on all present the same structure — something someone else built, operating with access you handed it, doing things you won't be watching in real time. Take a data connector as the parallel case: a revenue team wants to link Claude to their CRM so it can pull account status while writing renewal emails. Source: the CRM provider's own supported integration, or something a third party stitched together outside official channels? Reach: writing renewal emails only calls for reading a handful of fields on the accounts in play — yet plenty of connector setups default to full read-and-write access across the entire CRM, HR-adjacent fields included. Fit: read-only access limited to the relevant accounts matches the job; sweeping read-write access does not, no matter how much easier the default setup makes things. Both examples resolve to the same rule: hand over only the access the job actually requires, and reconsider that access once the job changes.

Task Statement 6.3 questions come in two flavors: an unclear-policy scenario, where the correct move is escalation, and a suspicious-content scenario, where the correct move is treating the content as untrusted. Both share the same underlying discipline — don't improvise around a gap, whether that gap is in written policy or in the trustworthiness of a piece of content.

• •✗ Improvising when policy is unclear instead of escalating to the policy owner.
• •✗ Assuming ambiguity in policy means permission to proceed.
• •✗ Trusting instructions embedded in a document or page as if the user wrote them.
• •✓ Escalating novel or unclear cases; treating all external content as untrusted data and validating outputs before acting on them.