What should a coding agent be structurally unable to do in a CRM?

Coming at this from access provisioning rather than CRM, but the same inversion held for us. I'm the founder of Lisar Connect, where the product issues VPN profiles to customers, so the sensitive verbs are the ones that mint or widen access rather than the ones that move money.

The ones we decided a generated or agentic path must not be able to call: issuing a profile bound to an account, changing what a plan entitles, and revoking or reissuing credentials. Not because an agent is uniquely likely to misuse them, but because those are the failures nobody reports. If a customer ends up with less access than they paid for, a ticket arrives within the hour. If they end up with more, it stays quiet indefinitely, so the only protection is that the action was never reachable.

The part of your post I'd push hardest on is where the boundary lives. A 403 is only a boundary if it sits below the surface the agent can regenerate. If the entitlement check is in application code the agent authored, a later prompt can rewrite it and the named test still passes, because the test was authored in the same pass and shares the same assumptions. What actually worked for us was moving the check into the issuing layer itself, so the request fails at the point where the credential would be created regardless of what the calling code believes about the actor.

One verb I'd add to your list: anything that emits outward and can't be recalled. Approve is usually reversible in a CRM. Send, publish and sign aren't. Reversibility might be a better sorting key than sensitivity.

And a question on Accordo, since you flagged that the actor is asserted rather than authenticated today: what currently prevents generated integration code from simply asserting the human actor when it calls the approval action?

The verbs I'd add to your list: merge and convert, for anything touching money. I'm not a programmer, I direct Claude to build Alisio, an invoicing tool for freelancers, and the near-miss I keep having isn't a rogue instruction, it's a "close enough" judgment call sneaking back in through a different code path than the one I checked last time. What's missing from this thread is how someone who can't read the diff verifies a structural refusal is actually structural and not just working today. My workaround is a manual black-box test I re-run before every change: try to make the app show a merged or converted number it shouldn't, and if it ever succeeds once, the constraint didn't move to hard code, it moved to hope. Slower than reading the enforcement layer yourself, but it's the only audit available to me.

The interesting product risk is that the security boundary is technically strong but commercially abstract. “The agent cannot approve” makes sense to builders, but the buyer may actually be worried about a more concrete failure: what could an agent accidentally commit the company to? That distinction matters because the product is selling control, not just 403 responses. I’d be curious whether Accordo’s positioning could make those business consequences more visible—especially around discounts, contracts, payments, and customer commitments—so the value is understood by someone evaluating the risk, not just the engineer implementing the boundary.

I’d make the human approval bind to an exact artifact, not just to the verb.

Otherwise there is a subtle gap:

the agent prepares quote A → human approves it → the agent changes a discount, recipient, term, or line item → the system still sees “approved” and allows the action.

I’d treat approval almost like signing a commit.

When the human approves a quote, store something like:

artifact_version + content_hash + policy_version + approving_actor

Then send, sign, or publish only succeeds if the current artifact still matches what the human actually approved.

Any material mutation automatically invalidates the approval and returns the object to pending_approval.

That also gives you a clean rule for generated applications: the agent is free to keep editing drafts, but it can never reuse human authority across different state.

It feels especially important in CRM workflows because the dangerous change may not be the final verb itself — it may be changing the evidence or commercial terms immediately before that verb executes.

Does Accordo currently bind an approval to the exact version of the object that was reviewed, or mainly to its workflow state?

Treating refusals as product surface is exactly right because what an agent "should be unable to do" is really a measurement system for organizational risk. You're not preventing bad behavior - you're measuring where the organization has to stay in control.

The structural boundaries you describe (403 HUMAN_APPROVAL_REQUIRED) are measurement points. They're forcing the system to measure "did a human make this decision" instead of trying to measure it through prompts that can be forgotten or overridden.

The leverage is that by making boundaries structural, you're also making the enforcement measurement automatic. Every approval that shouldn't happen gets tested. Every time the agent tries to cross the line, the organization gets data about where the line actually is.

Most organizations building with agents measure "did the agent follow the instruction" when they should measure "are the constraints still holding." Your framework essentially turns constraints into unit tests. The agent can't accidentally bypass a 403 because it's not about instruction compliance - it's about whether the HTTP response is correct.

For founders thinking about this: start by asking not "what should the agent never do" but "what do I need to measure to know the agent is still operating safely." Then make that measurement structural, not prompts.

Treating refusals as product surface is the right inversion. A prompt that says "ask a human first" dies the moment context truncates or a new tool opens a side door, so the boundary has to live in policy and return 403, with a test that fails if that ever softens. For a CRM I would put approve, sign, publish, pay, and change policy in the structurally unavailable set, and let the agent prepare evidence and draft the decision without ever holding the verb. The remaining risk is the actor assertion you already call out: if the agent can mint a human identity at deploy time, the 403 is theater.

The distinction between what an agent can generate and what it can never be allowed to do is a much more consequential design question than it initially appears.

The fact that you’re treating those boundaries as part of the product itself makes this especially worth watching.