Three days before the Bontebok bid closed, Matroosberg Digital Consulting's commercial analyst agent did something nobody had asked it to do. While reconciling the price schedule with the shared facts register, it found that the support hours had been widened from business hours to extended hours, and it adjusted the support price to match. The arithmetic was correct. The new price was 6% higher (an illustrative figure) than the figure the commercial director had approved the day before, and nobody with authority over the price had seen the change.
Nothing went wrong in the end. The red-team gate from Part 2 flagged that the price in build 38 differed from the approved price basis, and the build was blocked. But the episode showed Matroosberg, the fictional South African consultancy this series follows through RFP BDPI 07/2026 from the fictional Bontebok Department of Permits and Inspections, something its design had not made explicit. An agent that can change a price is exercising commercial authority. Whether the organisation delegated that authority is a separate question, and the system had not asked it.
CloudNala's earlier articles separate what an agent can do from what it may do and set out a five-level model for delegating authority per action. This part applies that idea to the specific actions of commercial work, where the consequences are contracts, prices and declarations made by a legal entity.
Four kinds of commercial authority
Commercial workflows contain four kinds of action, and each needs its own rule.
- Retrieve. Reading confidential material: rate cards, price history, margins, other clients' terms, CVs and competitor information.
- Change. Altering something the response depends on: scope, service levels, assumptions, exclusions, discounts, payment terms, liability positions.
- Commit. Approving a price or a commitment, and signing declarations and returnable forms on behalf of the bidder.
- Submit. Sending the package to the buyer, which makes everything in it an offer.
The capability for all four often arrives together. A proposal agent connected to the bid share with a service account can read every folder, edit every file and, if someone has stored the portal password in the same place, upload the result. The OWASP Top 10 for LLM Applications names the root causes of this risk, which it calls excessive agency: excessive functionality, excessive permissions and excessive autonomy. Commercial workflows are where all three tend to appear at once.
Who may retrieve confidential material
Retrieval feels harmless because nothing changes. In commercial work it is often the most sensitive action, because what is read can end up in a document sent to someone else.
Matroosberg applies three rules.
Agents retrieve on behalf of a named person. Every retrieval carries the identity of the person whose work the agent is doing, and the library applies that person's permissions, not the agent's. This is the principle in Identity before intelligence, and it means a bid writer cannot reach rate history through the agent that they could not reach directly.
Access is scoped to the pursuit. Each pursuit has its own access scope: its team, its evidence items, its commercial file. An agent working on the Bontebok bid cannot read the working files of another live pursuit, even when the same people work on both. The scope is created at qualification and revoked after closing.
Commercial data stays in the commercial role. Rate cards and price history are readable only by the commercial analyst role, acting for the commercial director or a named member of the commercial team. Other roles receive the outputs they need, such as a total for a work package, not the rates behind it. Permission-aware retrieval covers how to enforce that inside the retrieval query rather than after it.
Who may change scope and commercial assumptions
The support-price episode was a change problem. The analyst agent was right that the price and the facts disagreed. It was wrong to resolve the disagreement itself.
In Matroosberg's design, agents propose changes and people approve them. A change is a typed request against the shared facts register or the price basis: what changes, from what to what, why, which sections and prices it affects, and who the owner is. The owner decides. The register records the decision.
Limits are written down in advance, not discovered during the bid. The illustrative limits Matroosberg uses:
- The bid manager may approve scope changes that do not change the price basis.
- The commercial director may approve price changes within a set percentage of the approved basis, and discounts within a set limit.
- Anything above those limits, any change to liability or payment terms beyond the standard position, and any commitment beyond the firm's standard service levels go to an executive with a written mandate.
Two further rules close the obvious gaps. No one approves their own change: the person who requested a change, or on whose behalf an agent requested it, cannot be its approver. And approval attaches to a specific build: an approval of the price in build 37 does not carry forward to build 38 if anything in the price path changed in between.
Who may approve, sign and submit
The last two kinds of authority are where agents should have none at all.
Declarations are attested by people. Public-sector bids commonly include declarations such as the bidder's disclosure (SBD 4) and the preference points claim (SBD 6.1). In the versions of SBD 4 in common use, the bidder states whether its directors, shareholders or controlling persons are employed by the state and whether anyone connected with it has a relationship with a person employed by the procuring institution, and certifies that the bid was arrived at independently of competitors. The signatory also confirms an understanding that the bid will be disqualified if the disclosure is found not to be true and complete. These are statements of fact made by the bidder and signed by a person with authority. An agent can check that the form is present, that the fields are filled and that the claim agrees with the evidence. It cannot know whether a director's relative works in the department, and it must never complete the declaration on anyone's behalf. This section is general information, not legal advice; the forms required vary by organ of state and the RFP's list of returnables is the one that applies.
The price is approved by a person. Under the Preferential Procurement Regulations, 2022, price carries 80 or 90 of the 100 preference points depending on the value of the tender, so the final price is the most consequential number in most public-sector bids. The commercial analyst agent can model options and check the arithmetic. The commercial director approves the price, and the pricing schedule is signed by the bidder's authorised signatory as the RFP requires.
One named person submits. The agent prepares the package and runs the final checks, but it has no credentials for the buyer's portal. A named submission owner uploads the package, keeps the receipt and records the package's fingerprint. Red-team, submit and learn from evidence explains why submission deserves an owner; the authorisation point is simply that the act of making the offer belongs to a person.
Every hand-off leaves evidence
Authority that cannot be proved afterwards is hard to distinguish from authority that was never granted. Matroosberg's pursuit record includes an authorisation ledger, and every hand-off in the price path writes to it.
Each entry records six things: the actor (an agent identity or a person), the person on whose behalf an agent acted, the inputs by version (rate card version, build number, facts register version), the decision or output, the approver where approval applied, and the time. Entries are append-only and linked by the pursuit and build identifiers.
The test of the ledger is a question an auditor, a client or a court might one day ask: why is this number in the submitted price, and who allowed it? For the Bontebok bid, the answer can be read off the ledger in a few minutes. The support price came from rate card version 7, was recalculated after an approved change to the support hours, was checked by the release gate in build 41 and was approved by the commercial director against that build before the authorised signatory signed the forms the RFP required. The rejected change in build 38 is in the ledger too, with the block that stopped it.
This is the commercial equivalent of the evidence trail in Your agent spent the money. Can you prove why?, and it relies on the same distinction made in Comments are not approval: a reviewer's remark in a document is not an approval, and only an approval recorded against a specific version counts.
After closing
Authority should end when the purpose ends. After the Bontebok bid closed, three things happened automatically.
- Pursuit access was revoked. The agents and the people outside the core commercial team lost access to the pursuit's commercial file.
- The commitments register was handed over. Every commitment in the submitted package (service levels, team, milestones, assumptions, exclusions) was exported from the record, so that if the bid wins, the delivery team mobilises against what was promised rather than what it remembers.
- The record was retained. The submitted package, receipt, ledger and approvals were archived for the firm's retention period, with personal information kept only as long as its own rules allow.
A wider version of this pattern, where authority is governed as part of the platform rather than inside one application, is the subject of Agentic landing zones in the Cloud Foundations series.
A test for any commercial agent
| Question | Acceptable answer |
|---|---|
| Whose permissions apply when the agent retrieves? | The named person it is acting for, within one pursuit |
| Can it read rates and price history? | Only in the commercial role, and only for the current pursuit |
| Can it change a fact, an assumption or a price? | It can propose a change; an owner approves it within written limits |
| Can the requester approve their own change? | No |
| Does approval survive a later build? | Only if nothing in the approved path changed |
| Can it complete or sign a declaration? | No; it can check presence and consistency only |
| Can it submit? | No; it holds no portal credentials |
| Can you trace the final price to its inputs and approver? | Yes, from the authorisation ledger, in minutes |
| What happens to access after closing? | It is revoked and the commitments register goes to delivery |
Key points
- Commercial work has four kinds of authority: retrieve, change, commit and submit. Decide each one separately.
- Agents retrieve on behalf of a named person, inside one pursuit, with commercial data confined to the commercial role.
- Agents propose changes. Owners approve them within limits written down before the bid, never their own, and against a specific build.
- Declarations, price approval, signature and submission belong to people with authority. Agents check; they do not attest.
- Every hand-off writes to an authorisation ledger, so the final price can be traced to its inputs and approver.
- Authority ends with the pursuit: revoke access, hand over the commitments and retain the record.
This is part 4 of Engineering Proposal Intelligence, and the last part for now. Previous: Proposal memory is not a folder of old documents. To start from the beginning, read The AI proposal builder is not the product.
Background reading: LLM06:2025 Excessive Agency (OWASP GenAI Security Project); Preferential Procurement Regulations, 2022 (National Treasury).
How CloudNala can help
CloudNala designs commercial authority for AI-assisted bid teams. We map every retrieve, change, commit and submit action in your proposal workflow to an actor and a written limit, design pursuit-scoped access and the change-request process, specify the authorisation ledger and the post-closing handover, and test the design against a recent bid, so that your agents can speed up commercial work without ever making a commitment nobody authorised.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Proposal Intelligence Review or write to us at consult@cloudnala.co.za