AI governance
Who may know what: need-to-know in code, not by discipline
Starting questionHow do we make sure an AI function only sees the data its role and tenant allow, even if a developer forgets a check?
Result
Open
Design in testing: without a signed permission object, an AI call does not even compile.
By requiring every call to an AI component to carry a signed permission object that only a central policy service issues. Without it, the code does not compile. Need-to-know thus becomes a property of the architecture; the design is in testing.
What we tested
Until now, authorization hung on one middleware line per route. If that line is missing, the endpoint is open.
We designed a model in which every call to an AI component has to carry a signed permission object. Without it, the code does not even compile. Only a central policy authority may issue these objects. The design is in testing and not yet in production.
What it means for business architecture
Need-to-know becomes a property of the architecture rather than something code review has to catch. For regulated organizations that is exactly what matters: you can show that data access without approval cannot happen technically. Showing that it rarely happens is not enough.
Lessons learned
- A forgotten line is the typical data leak. Structural guarantees beat checklists.
- When components call each other, the risk multiplies. The check belongs at every handoff.
- Permissions need an expiry and a narrow scope, otherwise they turn into a master key.
- need-to-know
- authorization
- AI governance
- tenant isolation