Take this into your next conversation
The lesson in three points
- Identify who can change prompts, policies and production authority.
- Protect and review the path that changes an agent’s behavior.
- Keep test evidence and a recovery plan tied to the released version.
Free member resources · Sign-in required for downloads
- Propose a change
- Review authority
- Test the version
- Release & observe
Try it before you read
Teaching exercise: a policy change expands an agent’s refund limit. Name who approves the change, what tests must pass and how you would narrow or stop the behavior.
A fee-waiver assistant can approve up to $50. Someone opens a console, changes the limit to $500, and saves.
No model was retrained. No application binary was deployed. Yet the system can now authorize ten times the amount.
Your AI agent’s code didn’t change. Its authority did.
Who approved that change? Which service enforces the limit? And could you prove which policy applied to a waiver made a minute later?
This is the question at the center of Harden in my LLM-SHIELD framework: which changes can alter behavior, and how do you control them?
DreamBank is a fictional teaching example. Its fee-waiver amounts are exercise assumptions, but the design question is one you can bring to your next architecture review or system design interview.
1. Treat prompts and policies as production assets
A team may carefully review application code while allowing prompts, retrieval settings, tool definitions, or policy values to change through a separate console.
Those changes still matter. They can alter what an agent reads, recommends, or executes.
AI agent hardening starts by identifying these assets and giving each one an owner, a version, and an authorized path into production.
In the DreamBank example, saving a console edit should create a proposed policy version. The release process should determine whether that version may become active, for which scope, and from what time.
Start with your system prompt, policy bundle, guardrail configuration, retrieval rules, tool definitions, dependencies, and release workflow.
Ask: Who can change each asset directly, and what prevents an unapproved version from becoming active?
Include emergency access in that answer.
2. Approve the release—and authorize each action
Two decisions need separate controls:
* Release approval: Is this version of the system approved for production?
* Action authorization: May this actor waive this amount on this account now?
An approved release still needs to enforce permission for each business action.
The release process controls what enters production. The service performing the business action checks whether that specific action is allowed.
At the point where the account changes, the fee-waiver service should check identity, account scope, requested amount, current state, and the applicable approved policy.
A model’s confident explanation does not establish that these conditions hold.
Where human approval is required, bind it to the exact request and relevant conditions. If the amount, account, or policy changes, determine whether approval must be obtained again.
Try this: Approve a $50 waiver, then change the request to $500 before execution. Identify the exact control that should stop it.
For the broader authorization discussion, read AI Agent Security Starts Before the Agent Acts.
3. Revoke exposed credentials and verify the result
The October 24 session examined a real release-chain incident alongside the DreamBank exercise.
In its October 23, 2026 report, LiteLLM described an administrative key that remained valid after a follow-up commit deleted the configuration file containing it. The original commit remained in public history. An attacker later used the key to obtain more powerful access and alter the release workflow. Read LiteLLM’s incident report.
The operational lesson is specific:
1. Revoke the exposed credential at the system that accepts it.
2. Replace it where necessary.
3. Verify that the old value is rejected.
4. Investigate what downstream access it enabled.
Removing visible text does not revoke the credential.
Ask: What evidence would convince you that the exposed key can no longer be used?
Keep the documented incident separate from the fictional design exercise when explaining the lesson.
4. Check what a signature actually proves
A signature can help establish who signed particular bytes. It does not independently establish that those bytes are safe or approved for your environment.
For an application release, prompt bundle, or policy bundle, ask:
* Did it come from the intended source and build workflow?
* Does it match the exact version approved for release?
* Who could change or bypass those protections?
* What tests and recovery options support this release?
A digest identifies an artifact. Your controls determine whether that artifact is acceptable.
Review the exact version, run regression and adversarial tests, observe a bounded rollout where appropriate, and retain a known-good recovery target.
Ask: Could someone change the release workflow while still producing an artifact that passes your signature check?
5. Apply the right policy at the right time
Suppose DreamBank approves policy v8 to take effect at 09:00 tomorrow. A retriever finds both v7 and v8.
Both documents are authentic. Both quotations may be accurate. Only one may apply to the current action.
Select the applicable policy using its approved scope and effective time. Test cached retrieval as well as fresh retrieval.
Prompt and policy versioning must preserve the information needed to decide applicability: version, scope, effective date, timezone, and transition rule.
The newest upload is not necessarily the current policy. A historical explanation may correctly use an older version. A current action needs the policy required by the business’s execution rule.
If applicable sources still conflict, make the conflict visible and follow the defined review path.
Test the transition: For a rule based on execution time, check requests just before, at, and after the change. Include a request approved before the transition but executed afterward, and a cache still holding the previous version.
6. Plan for effects that rollback cannot undo
Restoring DreamBank’s $50 limit changes future behavior. It does not reverse waivers already committed under the wrong policy.
Recovery therefore needs more than a configuration rollback. It needs:
* An inventory of affected operations.
* An authoritative check of their outcomes.
* An owner for reconciliation or authorized compensation.
* A clear record of outcomes that remain unknown.
Protect the evidence used to reconstruct those decisions. Link the request, applicable policy, authorization decision, and observed effect. Apply access and integrity controls suited to the threat model, while keeping credentials and unnecessary customer data out of logs.
Ask: If the wrong policy ran for one hour, how would you identify the affected actions and decide what happens next?
Put the lesson to work in 20 minutes
Choose one capability, such as a fee waiver or delivery-address update. Then work through these five steps:
1. Name the change. What could expand its authority without changing the application binary?
2. Draw the release path. Who proposes, approves, and activates that change?
3. Locate enforcement. Which service checks permission before the business effect occurs?
4. Test failure. Try an unapproved change, a valid request, and a changed condition after approval.
5. Explain recovery. Show how you would contain the failure and reconcile past effects.
The useful result is a design another engineer can inspect and challenge.
I created two free, fillable companions to help you practice:
PDF downloads are free with your AI Architect Circle account. Sign in or create a free account to access them.
A four-page timed drill with a worked answer, interviewer challenges, a self-review rubric, and a design worksheet.
A five-page reference covering production assets, a release contract, policy versions, nine validation tests, and a readiness record.
Use the interview guide to rehearse your reasoning. Bring the architect reference to your next team review.
Watch the lesson and continue with the book
Recorded October 24, 2026, it follows the discussion from exposed credentials to release authority and the DreamBank policy exercise. The video description includes clarifications to the live discussion.
For the broader framework and more detail, explore my book, System Design with AI Interview Guide, published by Apress.
Get the book on Amazon · Read on O’Reilly
Bring your architecture or interview questions to AI Architect Circle.
In your system, who can change an agent’s authority without a code deployment—and what evidence would you inspect to verify that the change was authorized?
A fee-waiver assistant can approve up to $50. Someone opens a console, changes the limit to $500, and saves.
No model was retrained. No application binary was deployed. Yet the system can now authorize ten times the amount.
Your AI agent’s code didn’t change. Its authority did.
Who approved that change? Which service enforces the limit? And could you prove which policy applied to a waiver made a minute later?
This is the question at the center of Harden in my LLM-SHIELD framework: which changes can alter behavior, and how do you control them?
DreamBank is a fictional teaching example. Its fee-waiver amounts are exercise assumptions, but the design question is one you can bring to your next architecture review or system design interview.
1. Treat prompts and policies as production assets
A team may carefully review application code while allowing prompts, retrieval settings, tool definitions, or policy values to change through a separate console.
Those changes still matter. They can alter what an agent reads, recommends, or executes.
AI agent hardening starts by identifying these assets and giving each one an owner, a version, and an authorized path into production.
In the DreamBank example, saving a console edit should create a proposed policy version. The release process should determine whether that version may become active, for which scope, and from what time.
Start with your system prompt, policy bundle, guardrail configuration, retrieval rules, tool definitions, dependencies, and release workflow.
Ask: Who can change each asset directly, and what prevents an unapproved version from becoming active?
Include emergency access in that answer.
2. Approve the release—and authorize each action
Two decisions need separate controls:
* Release approval: Is this version of the system approved for production?
* Action authorization: May this actor waive this amount on this account now?
An approved release still needs to enforce permission for each business action.
The release process controls what enters production. The service performing the business action checks whether that specific action is allowed.
At the point where the account changes, the fee-waiver service should check identity, account scope, requested amount, current state, and the applicable approved policy.
A model’s confident explanation does not establish that these conditions hold.
Where human approval is required, bind it to the exact request and relevant conditions. If the amount, account, or policy changes, determine whether approval must be obtained again.
Try this: Approve a $50 waiver, then change the request to $500 before execution. Identify the exact control that should stop it.
For the broader authorization discussion, read AI Agent Security Starts Before the Agent Acts.
3. Revoke exposed credentials and verify the result
The October 24 session examined a real release-chain incident alongside the DreamBank exercise.
In its October 23, 2026 report, LiteLLM described an administrative key that remained valid after a follow-up commit deleted the configuration file containing it. The original commit remained in public history. An attacker later used the key to obtain more powerful access and alter the release workflow. Read LiteLLM’s incident report.
The operational lesson is specific:
1. Revoke the exposed credential at the system that accepts it.
2. Replace it where necessary.
3. Verify that the old value is rejected.
4. Investigate what downstream access it enabled.
Removing visible text does not revoke the credential.
Ask: What evidence would convince you that the exposed key can no longer be used?
Keep the documented incident separate from the fictional design exercise when explaining the lesson.
4. Check what a signature actually proves
A signature can help establish who signed particular bytes. It does not independently establish that those bytes are safe or approved for your environment.
For an application release, prompt bundle, or policy bundle, ask:
* Did it come from the intended source and build workflow?
* Does it match the exact version approved for release?
* Who could change or bypass those protections?
* What tests and recovery options support this release?
A digest identifies an artifact. Your controls determine whether that artifact is acceptable.
Review the exact version, run regression and adversarial tests, observe a bounded rollout where appropriate, and retain a known-good recovery target.
Ask: Could someone change the release workflow while still producing an artifact that passes your signature check?
5. Apply the right policy at the right time
Suppose DreamBank approves policy v8 to take effect at 09:00 tomorrow. A retriever finds both v7 and v8.
Both documents are authentic. Both quotations may be accurate. Only one may apply to the current action.
Select the applicable policy using its approved scope and effective time. Test cached retrieval as well as fresh retrieval.
Prompt and policy versioning must preserve the information needed to decide applicability: version, scope, effective date, timezone, and transition rule.
The newest upload is not necessarily the current policy. A historical explanation may correctly use an older version. A current action needs the policy required by the business’s execution rule.
If applicable sources still conflict, make the conflict visible and follow the defined review path.
Test the transition: For a rule based on execution time, check requests just before, at, and after the change. Include a request approved before the transition but executed afterward, and a cache still holding the previous version.
6. Plan for effects that rollback cannot undo
Restoring DreamBank’s $50 limit changes future behavior. It does not reverse waivers already committed under the wrong policy.
Recovery therefore needs more than a configuration rollback. It needs:
* An inventory of affected operations.
* An authoritative check of their outcomes.
* An owner for reconciliation or authorized compensation.
* A clear record of outcomes that remain unknown.
Protect the evidence used to reconstruct those decisions. Link the request, applicable policy, authorization decision, and observed effect. Apply access and integrity controls suited to the threat model, while keeping credentials and unnecessary customer data out of logs.
Ask: If the wrong policy ran for one hour, how would you identify the affected actions and decide what happens next?
Put the lesson to work in 20 minutes
Choose one capability, such as a fee waiver or delivery-address update. Then work through these five steps:
1. Name the change. What could expand its authority without changing the application binary?
2. Draw the release path. Who proposes, approves, and activates that change?
3. Locate enforcement. Which service checks permission before the business effect occurs?
4. Test failure. Try an unapproved change, a valid request, and a changed condition after approval.
5. Explain recovery. Show how you would contain the failure and reconcile past effects.
The useful result is a design another engineer can inspect and challenge.
I created two free, fillable companions to help you practice:
PDF downloads are free with your AI Architect Circle account. Sign in or create a free account to access them.
A four-page timed drill with a worked answer, interviewer challenges, a self-review rubric, and a design worksheet.
A five-page reference covering production assets, a release contract, policy versions, nine validation tests, and a readiness record.
Use the interview guide to rehearse your reasoning. Bring the architect reference to your next team review.
Watch the lesson and continue with the book
Recorded October 24, 2026, it follows the discussion from exposed credentials to release authority and the DreamBank policy exercise. The video description includes clarifications to the live discussion.
For the broader framework and more detail, explore my book, System Design with AI Interview Guide, published by Apress.
Get the book on Amazon · Read on O’Reilly
Bring your architecture or interview questions to AI Architect Circle.
In your system, who can change an agent’s authority without a code deployment—and what evidence would you inspect to verify that the change was authorized?
Resources for this article
Put the lesson to work.
Review who can change prompts, policies and release authority, and how you would test those controls.
Read the article freely. Sign in once for these PDFs; we’ll bring you back to this article’s resources. Newsletter updates are optional.
For your next interview
Interview Practice Guide
Practice defending prompt, policy and release-authority boundaries.
4 pages · Free member PDF
Get the interview guide ↓For your next design review
System Design & Architecture Review Prep Pack
Review hardening controls, change authority and evidence.
5 pages · Free member PDF
Get the review pack ↓Go deeper with the book.
Use Part Two’s trust, safety and ownership lenses to review the controls around production changes. System Design with AI Interview Guide develops these ideas through methods, fundamentals and applied systems.