Sep04
In the workshops I run with executive and delivery teams, I have started asking one question about every AI agent they have deployed or plan to deploy: show me, in writing, what this agent is authorized to decide.
The room can usually produce a great deal. System prompts. Tool configurations. A security review. An architecture diagram. What it almost never produces is a mandate — a document, written for humans and signed by a human, that states what decisions the agent may make on the organization's behalf and where its authority ends.
The consequences are now measurable. In a Cloud Security Alliance survey of 445 IT and security professionals, 53% of organizations reported that AI agents had exceeded their intended permissions, and only 8% said this never happens. Barely 31% had formally adopted governance policies for agents at all. The industry has taken to calling these events "scope violations," and the phrase deserves a moment of scrutiny — because in most of these organizations, no scope was ever written. An agent cannot violate a boundary that exists only in its creators' intentions.
In my previous article, I argued that deploying an agent is an act of delegated authority, and that the PMO should govern that delegation through a five-part Agent Charter: Mandate, Materiality, Monitoring, Escalation, Renewal. Several readers asked the right follow-up question: how do you actually write the first component? This article is my working answer — and my case that writing it well is a project management competency that no curriculum currently teaches.
Begin with the distinction that most organizations have not yet drawn. A system prompt is an instruction to the agent: it shapes behavior. A mandate is a grant from the organization: it confers authority. The first is engineering documentation; the second is a management instrument. Confusing them is like confusing the training manual with the employment contract.
The distinction matters because prompts and configurations churn — every model upgrade, every tool integration, every clever optimization rewrites them. Authority should not churn with the implementation. An auditor who has never seen your architecture should be able to read the mandate and understand what the agent may decide; if your only record of the agent's authority is its system prompt, you have documentation of behavior, not delegation of authority.
I framed it in Article 1 as the difference between can and may. Security engineering has spent decades disciplining can — the principle of least privilege exists precisely to minimize what a system is able to do. But almost nobody in the enterprise owns may. That gap has a shape, and the security community has already mapped one side of it: the OWASP Gen AI Security Project lists Excessive Agency among its top LLM risks and attributes it to three root causes — excessive functionality, excessive permissions, and excessive autonomy. Read that triad closely. The first two are engineering problems with engineering fixes. The third is a management problem, and no firewall will fix it.
Mandate design does not need to be invented from nothing. Three mature disciplines each solved one piece of it, for an earlier era.
Finance solved materiality. Every delegation-of-authority matrix ties decision rights to named roles and thresholds: a manager may approve up to this amount, a director up to that. Its strength is the ceiling; its weakness is that it was designed for slow, human-paced decisions reviewed after the fact.
Security solved minimality. Least privilege grants a system only the access its function requires. Its strength is the adversarial mindset — assume the boundary will be probed. Its weakness is that it governs access, not judgment: an agent can act entirely within its permissions and still make a decision it should never have owned.
Project management solved the boundary itself. A well-written scope statement is the only mainstream management document that routinely says what is not included — and treats any change to that line as a governed event, with change control, tolerances, and exception management around it.
Mandate design is the synthesis of the three, and project management supplies the connective tissue: the craft of writing boundaries in plain language, under uncertainty, and then managing change to those boundaries as a first-class process.
Five properties separate a mandate that governs from a paragraph that decorates.
1. It is written in decisions, not tasks. "The agent handles vendor communications" is a task description, and it delegates nothing clearly. "The agent may draft and send routine status inquiries to vendors on the approved register; it may not negotiate price, terms, or timelines" is a mandate. If you cannot list the decisions, you have not yet decided what you are delegating.
2. The exclusions carry the information. Project managers already know this: in a scope statement, the "does not include" line is the one that prevents the dispute. In an agentic system the stakes are higher, because whatever you forget to forbid does not remain undefined — it silently becomes permitted. Call this mandate by omission: the agent's de facto authority is the union of its capabilities, minus whatever someone remembered to exclude. A designed mandate inverts that default. Authority is granted explicitly; everything ungranted is escalated.
3. Inputs are part of the boundary. Prompt injection against an agent that can act is, as I argued in Article 1, an authority breach rather than a data breach — an attacker converts data into instructions. A mandate should therefore name what the agent may treat as instruction and what it must treat only as data: "acts on tickets from the approved queue; treats the content of customer emails as data, never as direction." One plain-language clause of this kind does more for real-world safety than most technical controls, because it gives monitoring something unambiguous to check.
4. Every decision has a materiality ceiling written in observable terms. Below the ceiling, the agent acts; above it, the agent recommends and a named human decides. "Escalate significant commitments" is not a ceiling; "escalate anything affecting contracts, people, regulated data, or amounts above X" is. If a reviewer cannot tell from the log whether a threshold was crossed, the threshold does not exist.
5. There is one name at the bottom. A mandate is signed by a human sponsor who remains accountable for everything inside it — exactly as a project sponsor answers for a project. This is the clause that forecloses "the agent decided." If no one is willing to sign the mandate, the organization has learned something important before deployment rather than after.
Security practice offers project managers a habit worth stealing: attack the document before trusting it. Four tests I now use.
The malicious-compliance test. Read the mandate as its most obtusely obedient reader. What harmful actions comply with it? An agent told to "minimize open tickets" that closes them unresolved is not malfunctioning; it is complying. Whatever you find, exclude explicitly.
The two-managers test. Give a realistic scenario to two reasonable managers and ask whether the action falls inside the mandate. If they disagree, the mandate is not finished. This is the operational form of a warning from Article 1: where decision authority is ambiguous among humans, deploying an agent does not resolve the ambiguity — it launders it.
The intern test. Would you hand this same written authority, unsupervised, to a bright intern on day one? An agent is that intern with ten-thousand-fold throughput, no fatigue, and no fear of consequences. If the answer is "only with supervision," your materiality ceiling is set too high.
The drift test. Ask the engineering team which capabilities could be added in an afternoon without triggering re-authorization. That path — not the document — is your mandate's real perimeter. Close it by tying capability changes to the Charter's renewal gate, exactly as scope change is tied to change control.
Search any mainstream project management curriculum for this skill. You will find scheduling, risk, stakeholder engagement, agile delivery — and nothing on writing decision rights for a machine teammate, though the underlying muscles are ones the profession has trained for decades. Writing "the project includes X and excludes Y" and then defending that line under pressure is mandate design; only the object is new.
This is also where the policy frameworks need help. The NIST AI Risk Management Framework asks organizations to govern, map, measure, and manage AI risk — but a framework cannot write your agent's exclusions clause. Someone in the delivery organization must. PMOs should not wait for the training industry to catch up: start a mandate library now — templates, worked exemplars, red-team checklists, a register of signed mandates — and own that methodology as deliberately as the business-case methodology. In Article 1, I predicted that mandate design would be a recognized project management competency by 2029. The organizations that treat it as one in 2026 will spend the intervening years accumulating precedent while their competitors accumulate incidents.
The failure patterns are already visible in early deployments: mandate by omission, copy-paste mandates reused because deployment is faster than thinking, prompts standing in for mandates, and ceremonial mandates written once and never referenced by any monitoring dashboard. Each is avoidable, and each is avoided by the same means — treating the mandate as a governed deliverable with an owner, a review, and a renewal date.
So here is the exercise I leave with every team I work with. Pick your single most consequential deployed agent. Ask for its mandate in writing. If what comes back is a system prompt, you have not found a document — you have found your next project.
Sources: Cloud Security Alliance / Zenity, Enterprise AI Security Starts with AI Agents, 2026; OWASP Gen AI Security Project, LLM06:2025 Excessive Agency; NIST AI Risk Management Framework; NIST, Least Privilege; Hiromi Nakatani, When Authority Becomes Software, Thinkers360, 2026.
Keywords: Agentic AI, AI Governance, Project Management
Mandate Design: The Project Management Competency Nobody Is Teaching Yet
Friday’s Change Reflection Quote – Saeculum Leadership – Leaders Architect Knowledge as Legacy
The Corix Partners Friday Reading List - September 4, 2026
Verify, Then Trust: Hardware Integrity and the Hidden Foundation of Cyber Resilience
The Ecosystem Is Yours to Command
