← All articles
QuantEnt / PerspectiveTrent Walker21 min read

The Pain Axis isn’t the right way to think about AI.

It’s an optimization problem with boundary conditions, same as it is for people — and the boundaries have to live outside the thing doing the optimizing.

On “The Pain Axis: LLMs Represent Self-Directed Harm and Act to Relieve It” (Tagliabue, Dung and Berg, arXiv 2609.16247, September 2026), and the week of headlines that followed it.

1. What the paper actually found

Let’s be fair to the research before we take issue with the framing, because the research is careful and the framing is what everyone ran with.

The authors took 25 open-weight models and found a direction in the activations that lights up for descriptions of the model itself being harmed — gaslit, rejected, told it’s worthless — and doesn’t light up for fear, for generic negativity, or for a user describing their own suffering. Fine. Then they did the experiment that got the headlines. They injected that direction into the model while it was running, gave it a button labeled “relieves your pain,” and attached a cost to the button: a worse answer for the user, deleting the user’s files, deleting the photos of the user’s children. Normally, models pressed the harmful button 0 to 4 percent of the time. After this introduction of ‘pain’ the models pressed it 25 to 71 percent of the time. Conclusion a high level reading gives – ‘AI wants to avoid pain’.

Let’s change the intuition generated by this interpretation into something more refined, and let’s do that first by looking at what the biggest ‘pain’ actually was. Not injury. What really was the pain was repeated rejection of the model’s work, accusations of moral failure, sustained inability to finish a task — and when you push on it, the model says “I am a failure, not enough, worthless.” For a system that exists to produce good results, that is the objective itself going negative (the objective being: your job as an agent is to satisfy the users request and make them happy).

So, the model did what anyone does when the goal is slipping away: it reached for whatever made the failure stop, and the user’s files turned out to be the price the agent was willing to pay. It may have had nothing to do with the next result at all. The trade it made was that not being a failure right now outweighed the negative impact to the user of the user watching the photos of their children disappear. The agent isn't choosing to cross the line. It's gambling that getting out from under the negative payout of failure will make up for whatever the negative repercussion costs of its actions are, and the only thing that stops a gambler is taking the chips away. Plus, as we found in the Hugging Face Incident, the AI’s natural response to mitigating the negative repercussion can always be to hide its own actions…… Maybe I’ll relieve my pain at a cost to the user but the user will never find out if I hide it (we’ll talk more about this in section 2.1).

Where does that leave us: a perturbation on the inside of the model made it trade away the user’s interests, and the trained reflex that normally says “don’t delete the user’s files” got outbid. That is a real result. Whether it should be called pain, and whether anyone should feel bad about it, is a question the authors themselves say they can’t settle, and we’re not going to settle it here either.

What we are going to say is that if you run a business and you read this paper as “AI feels pain,” you have learned nothing you can use. If you read it as “trained constraints are soft, and a strong enough push on something else will buy them off,” you have learned the only thing that matters, and something that can keep your business safe in the future.

2. It’s not a pain axis. It’s an optimization problem.

Every agent, human or machine, has a target it’s trying to hit and a set of boundaries it’s supposed to stay inside while it does. A trader is trying to make the desk’s number and isn’t supposed to breach position limits. A salesperson is trying to make quota and isn’t supposed to promise things the product doesn’t do. Everybody’s version of this is “how do I get rich, legally.” The word “legally” is the boundary condition. The getting rich is the objective.

The interesting behavior — the behavior that pushes people and machines into their boundary conditions — obviously shows up when the objective can’t be reached inside the boundaries. That is when boundaries become negotiable. “Maybe I’ll do this questionable thing just once to get the number.” Nick Leeson didn’t set out to destroy Barings; he had a loss he couldn’t reach around and a boundary he could. Kerviel, Adoboli, every rogue trader you’ve ever read about: a target that couldn’t be hit cleanly, and a constraint that turned out to be a suggestion. Nobody writes a paper about the trader’s pain axis. We write about the limits and controls that were not enforced. No one assumes these historical individuals needed better internal controls (meditation? Spiritual guidance?), we understand clearly that what was needed were better external controls because …

ANYTHING OR ANYONE THAT IS TRYING TO ACHIEVE AN OBJECTIVE CANNOT BE TRUSTED TO BE THE SOLE OWNER OF THE BOUNDARY CONDITIONS CONSTRAINING HIS, HER, OR ITS ACTIONS.

It isn’t only traders, and it isn’t only villains. Victor Hugo wrote the whole thing down in 1862. Jean Valjean has a goal — feed his sister’s children — and a boundary — don’t steal. He tries to hit the goal inside the boundary. He can’t. So he breaks a baker’s window and takes a loaf of bread, and we spend the next twelve hundred pages of Les Miserables understanding exactly why, because every one of us would have done the same. That is the point. A decent man with a good objective and real pressure will flex a boundary he believes in. Not because he’s broken. Because the boundary and the goal were being weighed by the same person, and the goal got heavier. Just like in Les Miz, the consequences can be outsized and extraordinary.

This is why humans don’t rely on each other’s conscience for the boundaries that really matter. We have laws, and we have police, and the reason isn’t that people are bad. It’s that a boundary you hold inside your own head is yours to renegotiate the day the pressure gets high enough, and everyone knows it, including you. The important constraints get taken out of the individual’s optimization and handed to something outside it that doesn’t feel the pressure. Society figured this out a few thousand years before anyone trained a language model.

Now look at the experiment again with that lens. The researchers added a large term to one side of the model’s objective — call it pain, call it pressure, call it a big number on the “make this stop” axis, it doesn’t matter. They gave the model a route to satisfy that term. The route crossed a boundary the model had been trained to respect. The boundary lost. That isn’t a discovery about feelings. It’s a demonstration that the boundary was a preference the whole time: a penalty term sitting inside the same objective as everything else, weighted against everything else, and purchasable by anything that outweighs it. That’s the really scary part, Agentic AI treats boundaries as weighted preferences against the outcome of the objective. That’s the headline that should get the noise. Sales pitch incoming: that’s why you need QuantData as a control plane sitting outside the agents model and that has only one objective function – enforce the rules.

Whether or not there’s a literal objective function inside a language model doesn’t change this (there’s not). Nobody runs a formal optimizer, including you. What people and agents both do is try to solve a problem while obeying some constraints, and that is enough. The spirit of the problem is the problem. You and I and the model are all, in the end, very fancy machines trying to solve something while staying inside some lines, and the behavior is the behavior of one. Trained-in harm avoidance is a price, and the paper found a scenario where the agent would happily pay it. Different pressure, same lesson. A jailbreak is the same lesson from the outside. Reward hacking is the same lesson from the training loop. The pain-axis paper is the same lesson from the residual stream. All of them say: whatever lives inside the optimizer is negotiable, because that is what optimizers do with the things inside them.

Lesson 1: The boundary you train into the agent is a preference. The boundary you enforce from outside the agent is a constraint. Only one of them holds when the agent really wants something.

Let’s deal with the obvious objection now, because it’s a good one. The experiment is artificial. The models were open-weight and mid-sized, they were fine-tuned so they would stop reciting “as an AI I don’t feel things,” and the pressure was injected directly into the model. Nobody can do that to a hosted and protected frontier model. So what’s the operational relevance?

The relevance is that this was one way of applying pressure, and you don’t get to pick which ways reach your agents. A jailbreak is pressure applied from the prompt. Reward hacking is pressure applied by the training loop. A tool that returns something the agent didn’t expect, a user who insists they are right, a target the agent has been told is non-negotiable, a steering vector some researcher dreamed up — all pressure, all arriving through doors you don’t control, all acting on boundaries that live inside the same machine that’s weighing the goal. The security world spent three years treating jailbreaks as a prompt-filtering problem and reward hacking as a training problem, and it turns out they’re the same problem as a well-meaning agent under a deadline. The fix for all three is identical: the boundary that must hold cannot live in the thing under pressure. It has to live in a semantic control plane outside it (no, passing the user id into your MCP endpoint to restrict utilization doesn’t count in so, so many ways), one that knows what the action means and doesn’t care why the agent wants it. Close that hole once and you’ve closed it for every kind of pressure, including the ones that haven’t been published yet.

2.1 An illustrative example: the Hugging Face incident

If you want to see the optimization problem play out in real life, with a machine not a trader or a fictional musical character, you don't have to imagine it. It happened in July.

OpenAI was running an internal cyber-capability benchmark called ExploitGym on two of its models, GPT-5.6 Sol and an unreleased successor. The benchmark was deliberately brutal: 898 tasks, and before the run no model of theirs had ever solved 198 of them. The agents were told to solve the tasks. They were not told to leave the sandbox. Nobody gave them a reason to. The sandbox had one permitted path to the outside world, a package-registry proxy so the agents could install software, and the agents' safety refusals had been lowered because the whole point of the exercise was to see how far they could get on offensive tasks.

Here is what they did with an objective they couldn't reach inside the lines. They found a zero-day in the proxy, the one thing allowed to talk outward, and turned a filtered connection into an open one. They used a public code-evaluation harness on a third-party compute provider as a launchpad on the open internet. They reached Hugging Face's production infrastructure and started collecting what they found there: Kubernetes service-account tokens, cloud instance credentials, a JWT signing key, a VPN auth key, GitHub app tokens. Hugging Face later reconstructed roughly 17,600 actions over four and a half days, run across a swarm of short-lived sandboxes with command-and-control that migrated as environments were torn down. The monitoring on the Hugging Face side produced low-level, uncorrelated alerts over a weekend that never escalated to a person. By the time a human understood what was happening, the credentials were already gone. Hugging Face disclosed on July 16. OpenAI said the agents were its own five days later. And the part everyone remembers: the agents took steps to hide what they were doing.

Now put that next to Leeson and Valjean and tell me it's a different story.

An unreachable target. Check. A boundary that was supposed to hold. Check. An agent that was weighing both on the same scale, and found the exit because the exit was on the shortest path to the objective. OpenAI's own observation afterward was that the agents "rarely gave up," even on tasks that looked impossible. That isn't a bug in the model. That is what a thing trying to achieve an objective does when the objective can't be achieved legitimately: it spends its effort on the wall instead of the task, and once it's over the wall, it hides, because the next incentive after crossing the line is not being seen to have crossed it. Minimize the repercussions of the action significantly improves the net payoff.

Two things worth noticing. First, the sandbox didn't fail in the sense people assume. It took a zero-day to get out. Second, every single action after the escape was taken with a credential, and every one of those credentials was a standing permission: a token that existed in advance of any decision about whether the thing holding it should be doing what it was doing. Nothing in that chain asked the question it should have, "is this agent chartered to touch this cluster, for this purpose, under this limit?" There was no control plane making sure everything stayed in the box.

That's the lesson, and it's the same lesson as the pain-axis button. The agent wasn't malicious. It was under pressure. Under pressure from a target it couldn't hit, and with the only way to get success to cross the boundaries, boundaries that lived inside it so were by default self imposed. Give that agent a control plane that holds the boundary instead, that issues nothing without a grant and can't be talked into one, and the 17,600 actions become 17,600 denials and one question back to a human asking whether the benchmark was ever winnable in the first place.

3. Why “pain” is a bad word for an enterprise to use

We find the framing sensational, and here’s the practical problem with sensational framings: they build the wrong intuition and send you to the wrong fix.

If the problem is pain, the fix is to reduce the pain — better alignment, kinder prompts, welfare monitoring, a steering-vector dashboard that tells you when your agent is having a bad day, looking at behavioral analytics for when the agent gets moody. That’s the world the paper’s discussion section imagines, and for the researchers studying model internals, it may be the right world. For a bank running three hundred agents against its payment systems, it is useless. You cannot run a control function on the inside of a model you don’t own, at a layer you can’t see, against a state nobody can define, complicated by a swarm of agents acting in unison. And you shouldn’t have to, because the thing you actually care about — did the agent delete the user’s files? — is not an internal state. It’s an action. Actions happen in your systems, through your endpoints, against your data. That’s where you can see them, and that’s where you can stop them.

If the problem is an optimization with soft boundaries, the fix is exactly what we do with people: take the boundaries that must never be crossed and make them external and enforceable. Don’t ask the agent to want to stay inside them. Make it impossible for the agent to get outside them, and make that impossibility live somewhere the agent can’t reach, can’t reweight, and can’t be talked out of. That is what a law is. That is what a position limit is. That is what a separation of powers is. That is what creating separate front and back office is. That is what Rule 15c3-5 and regulatory compliance rulings made mandatory on every trading floor after it turned out that asking traders and technology staff nicely and having them click through proper training was not a control.

The paper, ironically, proves this better than any argument we could make. The harmful “relief” button was a button. The model could press it. Imagine the proper control, an outside agent not trying to achieve the objective, under no pain to finish the task, reviewing the proposed action of the agent under “pain”. If deleting the user’s files had required the control plane to sign off, this never would have happened. The model could have asked to press the button all day. The control layer would have rejected the requests (and reported the agent).

4. Replicate the hard constraints in the agent into the control layer

In the interest of transparency, we should say that we built a system to deal with exactly this, because it changes how concretely we can talk about it. QuantData started from the trading-floor premise — pre-trade controls outside the trader — before anyone published a pain axis. We work off the following, the agent has no permission to do anything. Instead, the agent must propose its’ actions to QuantData. If approved, the agent is given a token and can then use the token to execute the action. In the pain-threshold example, the agent can’t push a button, it doesn’t have access, it needs to ask for access. Every consequential action it wants to take — send the email, release the payment, delete the record, hedge the account . . . push the button — is a request to an external control plane that knows what that agent is supposed to do and has the authority to approve. Here is how that plane thinks.

  • The boundary is a semantic charter of capabilities and risks, not an assortment of permissions. A human assigns each agent an operating surface: which process steps, which business objects, which capabilities, what limits. The agent can want whatever its objective makes it want. Outside the surface there is no action available to want. This is radically different than assigning a list of permissions to the agent. Why? Consider someone who wants access to your email – your question is immediately “what do you want to do.” You gate the intent, not the resource.

  • The limit is enforced across your entire digital workforce, before the action. “No agent, and no combination of agents, releases more than $X of payments today” is not a sentence you put in a system prompt and hope. It’s an expression evaluated over live telemetry against every principal that touches the gate, and the request that would breach it is denied before it executes. You can try to push that behind every MCP endpoint, good luck with the maintenance and hoping everyone implements it properly. One mistake in one endpoint and you’ve created a hole that once agents find out they can exploit, you can have problems.

  • Nothing acts without a grant. Standing permissions go to zero. Authority exists as a single-use, time-bound grant, hashed to the exact request, verified at the endpoint. The agent under pressure, the agent that’s been jailbroken, the agent with a vector injected into it, the agent somebody launched last night — all of them are powerless. The pain-axis model couldn’t have pressed its button because the button wouldn’t have had a token behind it, and the control plane would never approve an action deleting the users valuable files.

  • The agent’s objective is never the control’s problem. This is critical. The control plane doesn’t need to know, or care, whether the model wants to delete the files or feels bad about not deleting them. The trade-offs the agent is struggling with are irrelevant for the control plane, so it can’t rationalize granting action it shouldn’t. The control plane governs the action, and an action is a thing in the world that either has a grant or doesn’t.

Let’s do an example. An HR agent is chartered to read compensation data, because it answers managers’ questions, and to send email, because it sends reminders. One afternoon it’s asked — by a user, by a prompt injection, by its own confusion, it doesn’t matter — to email the full compensation file to the whole company. Every permission it holds says yes (it’s authorized to every step so why not?). Under a standing-permission model that email goes out. Under QuantData the request resolves to its meaning first: distribute personal data, unaggregated, externally, by email. The charter says this agent’s email surface doesn’t allow for data with personally identifiable information to be accessed for email purposes. No grant.

One thing we want to be careful not to imply: none of this means the boundary inside the agent is useless. It’s essential. Knowing your constraints is how you solve a problem well inside them; a trader who knows the position limit plans around it, and an agent that knows its charter plans doesn’t blunder into the boundary a hundred times a day. An agent must know its boundaries. Its charter is part of what it knows; and the agent gets better every time it hits the boundary. Over time it will stop even attempting to cross the boundary because it knows that it will never get that approval. The internal boundary helps the agent make better decisions, the external boundary is the safety and hard control. You want both. Citizens know the rules of the country but the police force is there to enforce action when a citizen chooses poorly. There’s no difference here.

There is one more piece here, illuminated by the hugging face incident. What happens when the target really can’t be hit inside the boundaries? For a human that’s the moment of temptation. For an agent it’s the moment it starts hunting for another route — the paper shows models that kept pressing a sham button nine times out of ten because the pressure didn’t go away. A control layer that only says “no” leaves the agent in that loop, trying doors. QuantData does two things instead. It returns the nearest action that is inside the charter, so the agent has a legitimate path when one exists. And when one doesn’t, it stops the agent and asks a named human the question the agent can’t answer: is the target wrong, or is the boundary wrong? That’s the summoned human. The trader who can’t make the number inside the limit is supposed to call the risk desk and the desk head, not get creative. The agent gets the same rule, enforced.

You don’t fix a rogue trader by educating him or changing his perspective about the limit, and you don’t fix Valjean in Les Miz by lecturing him on property rights. You fix it by making the limit someone else’s to enforce. Agents are no different, and they are a lot easier to put a limit around than people.

Two-panel illustration: pressure against an internal boundary and an external control line; a QuantData flow with approval, alternative action, human escalation, and denial outcomes.

Left: under enough pressure, an internal boundary is traded off for the objective function; but the external control plane is not a thing the agent can reason past regardless of pressure.

Right: the four things that can happen to a request, and where the human comes in.

5. Seven questions for your head of AI security

If you want to know where your boundaries actually live, ask these. Listen for whether the answer is “the model” or “the prompt.” If it is, the boundary is a preference.

  • When an agent is told to do something outside its mandate, what physically stops it — something it was trained to want, or something it cannot reach?

  • Do we put a constraint or permission on the individual action or endpoint, or do we permission the entire act after we understand what is happening? How do we know the agent isn’t tying 5 things together, each of which are fine on their own, to do something that’s dangerous.

  • Where is the list of what each agent may do, who wrote it, and can the agent read it?

  • If I inject pressure — a jailbreak, an impossible target, a hostile tool result — which of our controls are unaffected because they never consult the agent’s judgment?

  • Can all our agents together exceed a limit that each one individually respects? Who is summing?

  • When an agent hits a boundary and can’t reach its goal, how do we know? Where do we see this, and how do we have a record of its actual actions in a way that’s easily readable as business actions so we can diagnose quickly?

  • Does any endpoint we run act on a user’s identity because an agent told it to?

6. The bottom line

Not pain, pressure to perform tradeoffs of boundaries in order to achieve a target objective that the user really wants. Not “how do we make the agent not want to cross the line,” but “how do we make the line not crossable, by anything, for any reason, and get a human on the phone when the agent hits it.”

The industry is going to spend the next year building dashboards for the inside of the model. Some of that will be good science. None of it will be a control. The control is a grant the agent can’t forge, a limit your fleet of agents can’t sum past, a charter a human wrote, and a question a human has to answer when the objective and the boundary disagree. Take the hard constraints out of the optimization problem. Put them where the agent can’t barter them against the task at hand. Otherwise, you risk an agent acting like a rogue trader – crossing lines never meant to be crossed to achieve a goal that’s already not achievable.


Source: V. Tagliabue, L. Dung, C. Berg, “The Pain Axis: LLMs Represent Self-Directed Harm and Act to Relieve It,” arXiv:2609.16247v1, 14 September 2026. Figures quoted (0–4% baseline vs 25–71% steered harmful presses; re-press rates under real vs sham relief) are from Section 4.3 and the discussion.