Hiding is not blocking: why hiding a button does not protect your data

In two lines: if someone cannot see a button, that does not mean they cannot use what sits behind it. If the data is still within reach by another route, the control is decorative. Here are three of our own cases, the trap of the control that fails open, and three questions to check whether it is happening to you.

The covered door and the bricked-up door

Picture a door in your office wall that you do not want anyone to use.

You can hang a painting over it. The door disappears from view, nobody uses it, and the matter looks settled. Or you can brick it up: remove the frame, close the gap, stop it being a door at all.

Both look the same from the corridor. Only one is a wall.

Software works the same way. When someone tells you a user "cannot" do something, it is worth asking where that "cannot" actually lives.

Almost always it lives in the interface. The button does not appear, the tab is hidden, the field is greyed out. And there the matter rests, because in practice nobody does it.

The problem is that the interface is only one of the entrances. Underneath any application there is an API (the door programs use to talk to each other, bypassing every screen), and that API serves requests wherever they come from. If the permission was enforced only by drawing or not drawing a button, the operation remains available to anyone who knows how to ask the API directly. No sophisticated attacker required: in many cases it is enough to open the developer tools built into any browser and watch which requests the application itself is making.

That leaves two situations that look very similar from outside and have nothing in common underneath:

• Forbidden: the system could do it, but we trust nobody will ask.
• Impossible: the system cannot do it even when asked.

Only the second is a control. The first is an expectation of good behaviour.

Three of our own cases, and none of them theory

These are not textbook examples. They are failures in our own systems, found in internal reviews and fixed.

1. Assessment scores could be modified by the person being assessed. We run a platform where sales teams train with virtual customers, and every session ends with a score per competency. In the interface there was never any way to touch them: no button, no field, no way to try. But auditing the database permissions revealed that every user held write access to their own record, assessment columns included. Nobody ever did it. Anyone could have, and without leaving any obvious trace. The permission was revoked column by column: those scores are written by the system with its own credentials, not by the person.

2. The team directory could be dumped without logging in. An internal function returned the name, department and job title of every employee, and it was reachable by the anonymous profile, meaning anyone arriving without identifying themselves. It appeared on no public screen, but it answered whoever called it. Revoked.

3. A backup could be triggered by anyone. The process that exports our CRM to external storage authorised itself with the application's public key. And "public" here is literal: that key travels inside the code of any website using the system, and it is designed to be visible. It exposed no data, since the export goes to our own storage, but it let an outsider run it at will, with the consumption that implies. It now requires a token that only lives on the server.

All three share the same shape: the control sat where people look, not where the system decides.

The control that fails open

There is a second, quieter problem, and it is the one worth really understanding, because it never warns you.

A control can be correctly placed and still behave badly the day something breaks.

Think of the doorman in an office building. He has a list of who may go up to each floor. One day the list does not reach him. What does he do?

• Fails closed: when in doubt, nobody goes up. Someone complains they cannot reach their own office, and you find out the same day.
• Fails open: when in doubt, everybody goes up. Nobody complains and everything runs smoothly.

In software it works exactly the same: a permission check that queries a service and gets no answer can deny by default or allow by default. The second option is the dangerous one, precisely because it generates no signal. The system appears to work better than ever. Controls that fail open are not discovered by using the product: they are discovered in an audit, or once something has already happened.

And with AI agents this multiplies, for a very specific reason: an agent insists. A person who hits an error tries again, maybe a third time, then calls someone. An agent retries systematically, tries alternative routes and carries on without tiring. A control that lets 1% through, faced with something that tries a thousand times, has stopped being a control.

Three questions to check this in your company

You do not need a project or any coding knowledge. You need to ask three questions to whoever runs your systems, and listen carefully to the answer.

1. Take a permission you assume is enforced. For example: "a salesperson cannot see another salesperson's accounts." Ask: is that blocked on the server, or merely hidden in the interface?

2. Ask what happens when the check fails. If nobody can answer you, the answer is usually that it fails open. Nobody designs a system to fail open: it simply never got decided, and that is where it landed by default.

3. Ask them to prove it. A real control can be demonstrated: the operation is attempted against the API, in front of you, and the system refuses it. If the demonstration is "look, the button isn't there", there is no control.

In front of an auditor, the sentence that counts is not "we have forbidden it". It is "they cannot". And that sentence has to be backed by a reproducible test, not by a screenshot.

The point, in one sentence

A reliable control is one that removes the capability, not one that forbids it. Anything else is a house rule: useful while everyone cooperates, useless the day someone does not, or the day an agent automates the attempt a thousand times over.

Of the three cases above, not one was found by an attacker. We found them ourselves, by looking at where each permission actually lived. That is the exercise, and it is considerably cheaper done early than late.

Want to know how a team of agents is governed with controls that hold up in front of an auditor? Download our Digital Workforce guide.

---

Content developed with the support of AI and supervised by the editorial team at Digital Transformations.