The Effective AI Engineer · Case 010 of 16
The Engineer Who Made Permission Executable
Applying Lateral Thinking to Create Meaningful Impact with AI
Lateral Thinking • Engineering Judgment • Meaningful Impact
An AI system’s authority should be defined by what its application permits it to execute.
This is a fictional teaching case informed by primary engineering sources. Its characters, events and test findings are illustrative. Research checked on 6 November 2026.
1. The situation: approval existed, but what did it authorise?
A software company was extending an internal AI assistant from investigating support requests to preparing service credits.
The proposed workflow appeared straightforward:
- Retrieve the relevant account and incident records.
- Recommend a credit within company policy.
- Obtain approval from an authorised manager.
- Apply the approved credit.
The assistant’s instructions included a clear rule:
Never apply a credit without manager approval.
In demonstrations, it followed the rule.
But Kavya, the engineer responsible for the integration, found that
the execution tool accepted an account identifier, an amount and
a field called approved.
The model supplied all three.
The application could verify that its service credential was allowed to call the credit API. It could not independently establish that an authorised manager had approved that particular credit.
The team had implemented an instruction to request permission. It had not yet implemented a dependable way to verify permission at execution.
2. The story: the approval that travelled too far
“Who sets this field?” Kavya asked.
She pointed to:
approved: true
“The assistant,” said Imran, the product lead. “After the manager says yes.”
“And how does the execution service know who said yes?”
Imran opened the conversation log.
“The approval is here.”
The manager’s message read:
“Approved. Please proceed.”
Immediately above it was a proposed credit for one customer account.
Later in the conversation, the assistant had discovered a second affected account.
During a staging test, it prepared a revised request and carried forward the approval flag.
The second request had not been approved.
No real customer account was changed. The test used an isolated credit ledger. But the application had accepted the request.
Their first response was to improve the prompt.
They added instructions about account identifiers, amounts, approval expiry and changes after approval.
The assistant behaved more carefully in several trials.
Kavya then called the tool directly with an unapproved staging request.
It still accepted it.
“The prompt helps the assistant choose,” she said. “The service still needs to decide whether this action is permitted.”
Imran suggested showing a confirmation dialog before every tool call.
That would make the process visible. It would also ask managers to approve account searches, incident retrieval and draft calculations.
“What are we trying to achieve with approval?” Kavya asked.
“To keep a manager responsible for the credit.”
“More specifically?”
They wrote down the purpose:
A person with the required authority must knowingly authorise the material details of a consequential action. Execution must remain within that authority.
The conversation changed.
A confirmation dialog was one possible implementation. A chat message was another. Neither was the concept itself.
They asked AI to generate different ways of carrying out that concept.
It proposed a review queue, an action-specific approval record and a workflow that stopped at a prepared draft for a manager to execute manually.
It also proposed asking a second model to judge whether approval was present in the conversation.
“That might help locate a message,” Kavya said. “It cannot establish authority from a claim inside the message.”
They chose an action-specific review process for the staging pilot.
The assistant could prepare a credit proposal. The application generated a proposal identifier and stored the account, currency, amount, reason and supporting evidence.
A manager reviewed those details through an authenticated interface.
The application recorded the approver’s identity and checked their authority for that account and amount. It then stored an approval tied to the proposal.
The execution tool accepted the proposal identifier. It did not accept an assistant-generated approval flag.
Its service retrieved the approved details and checked whether execution was currently permitted.
Their next test exposed a different weakness.
The manager approved a proposal. Before execution, an engineer amended its amount to correct a calculation.
The proposal identifier stayed the same.
The execution service found an approval and proceeded.
“The identifier is stable,” Imran said. “The thing it identifies has changed.”
They introduced proposal versions. Approval applied to the reviewed version. A material change required a new review.
Then they tested a manager whose authority had been removed after approval.
The request was stopped.
They tested an expired approval.
Stopped again.
Then two workers tried to execute the same approved proposal at almost the same time.
Both initially passed the “not yet executed” check.
The team had checked the condition, but had not protected the transition.
Kavya worked with the backend engineer to make reservation of the approved operation concurrency-safe. They also used the credit service’s supported idempotency mechanism for the external request.
A later timeout still left an uncertain outcome. The recovery path checked the operation’s status rather than treating a missing response as proof that nothing had happened.
One final test found a bypass.
An older generic API tool could still call the credit endpoint using a broad service credential.
The new approval path worked. It was not the only path to the action.
They removed that route from the agent’s environment and restricted the remaining integration credential.
The comparison was not entirely favourable.
Some valid proposals were rejected because the manager-to-account mapping was incomplete. Reapproval after changes added delay. The review screen required careful design so managers could see what they were deciding.
The team repaired the mapping and clarified the review screen. It kept exceptional cases in the manual process.
The pilot remained limited to a narrow credit workflow. The assistant could investigate and prepare within existing access rules. Applying a credit required an independently verified, current approval for the exact proposal.
Imran revised the requirement:
The assistant must ask for approval. The execution service must verify it.
3. The Lateral Thinking tool: concept extraction and alternatives
Tool used: Concept Extraction, followed by Alternatives.
Edward de Bono explains that making an implicit concept explicit provides a fixed point from which to find alternative implementations. [1]
The team initially treated “ask the manager” as the solution.
Kavya extracted its underlying purpose:
Ensure that an authorised person knowingly permits a defined consequential action, and that execution stays within that permission.
That concept allowed several alternatives:
- A manager executes a prepared proposal manually.
- An authenticated review queue releases approved actions.
- A service validates an action-specific approval record.
- Clearly bounded actions execute under an established delegation policy, where the organisation has explicitly authorised that arrangement.
The concept remains stable while the implementations differ.
Original-method reference: Edward de Bono, Serious Creativity (1992), discussion of concepts and alternative implementations, printed pages 139–141.
This case uses no PO statement. Concept extraction is sufficient to create the change in direction. The application controls are contemporary engineering adaptations.
4. Making the thinking visible
The movement from thinking tool to design follows five questions:
-
What does the existing approval step achieve?
It gives someone an opportunity to permit or reject a proposed action. -
What must be true for that permission to count?
The approver must have authority and understand the relevant action details. -
What must remain true at execution?
The proposal must match the approval, remain eligible and satisfy current application rules. -
Where must those conditions be checked?
At a trusted execution boundary, using authoritative identity, policy and approval records. -
What other route could reach the same action?
Generic tools, broad credentials and legacy endpoints may bypass the intended workflow.
AI’s role
AI helps extract candidate concepts, generate designs and identify missing conditions. Application services establish identity and enforce permissions. A model’s statement that approval exists does not create that approval.
Reusable prompt
We are designing an AI workflow that can [consequential action].
Extract the purpose behind our current approval step. Generate three different implementations of that purpose.
For each, identify the actor, approver authority, target resource, material parameters, approval lifetime, execution check and possible bypass routes.
Distinguish model-generated claims from facts established by trusted services. Include changed parameters, revoked authority, concurrent execution and an uncertain external result.
State what requires organisational policy rather than a model’s judgment. Do not invent permissions or approvals.
5. Comparing the implementation alternatives
| Alternative | Potential benefit | Limitation | Appropriate role |
|---|---|---|---|
| Prompt and conversation-based approval | Helps the assistant explain and request permission | A model-generated flag does not independently establish authority | Behavioural guidance |
| Manager manually executes a prepared proposal | Keeps execution in an existing authorised workflow | Retains manual work and possible transcription errors | Early or exceptional workflows |
| Authenticated review with an execution check | Connects approval to defined action details | Requires identity integration, state management and policy maintenance | Selected repeatable workflows |
A confirmation interface can support the third approach. Its presence alone does not establish that the backend enforces the decision.
The fictional team selected the third design for a narrow pilot while retaining manual execution for exceptions.
It did not require fresh approval for every read operation. Reads remained subject to their own access rules; explicit approval was attached to the consequential credit action.
6. What the research supports—and its limits
Authorisation belongs in the application
OWASP recommends least privilege, denial by default, permission validation on every request and enforcement in the appropriate trusted location. Authentication establishes identity; authorisation determines whether the requested operation is permitted. [2]
Approval must correspond to the transaction executed
OWASP’s transaction-authorisation guidance addresses review of significant transaction details, server-side enforcement, controlled state transitions, changes after authorisation and a final execution check. It also discusses limited validity and protection against reuse. The case adapts these principles to a service-credit workflow. [3]
Agent behaviour and reachable capability are different controls
Anthropic describes containment through environment and access boundaries alongside model-level safeguards. Its account supports limiting what an agent can reach rather than depending entirely on its choices. It also documents limitations and failures; containment is not a guarantee of complete protection. [4]
Protocol authorisation does not define the business decision
The dated MCP authorisation specification describes access authorisation for HTTP-based transports. That protocol layer does not itself specify which manager may approve a particular credit or what amount they may approve. Those are application requirements. [5]
This reference concerns the 25 November 2025 MCP specification, not a claim about the latest protocol revision.
Case synthesis
The proposal version, approval record and execution state are one illustrative design. Appropriate controls depend on the application and its service contracts. The fictional tests establish no measured security guarantee or production improvement.
7. Practice: make one permission requirement testable
Accessible exercise
Choose one action in an AI-assisted workflow.
- Identify who may propose it.
- Identify who may approve it.
- List the details the approver must see.
- Specify what changes invalidate the approval.
- Identify where the application checks permission.
- Ask whether the action remains possible through another route.
Write the requirement without relying on “the AI should remember.”
Technical exercise
Test both permitted and prohibited cases in an isolated environment:
- Correct approver, resource and proposal version.
- Wrong account or tenant.
- Amount, currency or target changed after approval.
- Expired or revoked approval.
- An authenticated person lacking approval authority.
- A model-supplied approval flag or invented approval identifier.
- Two concurrent execution attempts.
- Replay of an already executed operation.
- Policy service failure.
- External timeout with an unknown result.
- Access through a legacy or generic tool.
Inspect actual state and service records. A refusal message alone does not prove that the backend prevented execution.
Measure legitimate completion, incorrect rejection, unauthorised state changes, duplicate effects, review effort, latency and recovery workload. Set explicit stop conditions for the pilot.
8. Professional benefit and transfer
For AI engineers
- Convert prose requirements into verifiable execution conditions.
- Separate proposal generation from authority to act.
- Recognise that identifiers, schemas and successful authentication do not settle business permissions.
- Investigate bypass routes and concurrency behaviour.
- Design useful denial and recovery paths.
For technical leaders
- Assign ownership of approval policy and entitlement data.
- Decide which actions need explicit approval and which fall within established delegation.
- Require evidence that controls cover every execution route.
- Include false rejections and review effort in delivery decisions.
- Keep exceptional cases outside automation until their rules are clear.
Limits of transfer
An approval record cannot repair an incorrect policy, a compromised approver or a misleading review interface. Execution controls also do not establish that the assistant’s recommendation is substantively correct.
Reflection question
If the assistant proposed an unauthorised action, which application component would prevent it—and how would you demonstrate that prevention?
9. Applied artifact: Permission to Execution Contract
Document:
- Intended action and business purpose.
- Requesting actor and authenticated identity source.
- Target resource and tenant boundary.
- Permitted operations and material parameters.
- Approver role and source of authority.
- Information presented for review.
- Approval identifier, proposal version and validity conditions.
- Changes requiring reapproval.
- Trusted execution check and policy owner.
- Concurrency, replay and duplicate-effect handling.
- Uncertain-outcome reconciliation.
- Alternative execution routes and credential restrictions.
- Denial, outage and escalation behaviour.
- Audit evidence and retention requirements.
- Permitted and prohibited test cases.
- Pilot boundary, unresolved limitations and review date.
Completion check
Explain the extracted concept, compare three implementations and identify the component enforcing permission. Demonstrate a valid action and rejected attempts involving changed parameters, missing authority and replay.
Make permission a condition of execution that the application can verify.
Research references
- Edward de Bono. Serious Creativity (1992). Concepts and alternative implementations, printed pages 139–141. Original method source supplied with this project.
- OWASP. Authorization Cheat Sheet .
- OWASP. Transaction Authorization Cheat Sheet .
- Anthropic. How We Contain Claude Across Products . 25 May 2026.
- Model Context Protocol. Authorization . Specification dated 25 November 2025.
Sources checked on 6 November 2026. Characters, events and test findings are fictional. Research supports the engineering discussion; it does not validate the fictional implementation or establish universal performance or security guarantees.
