Trust is Engineered: Security and Governance Inside the Labs Stack

Trust is Engineered: Security and Governance Inside the Labs Stack

Clients no longer accept trust for data security, and they are right to be cautious. The honest answer is architecture. Here is how governance is built into every tool in SLW Labs, SILO included.

The question comes up in nearly every serious conversation with in-house counsel, and it is the right one to ask: where does our data go, and who can see it? A decade ago a firm could answer with a policy and a reassuring tone. That era is over. A policy is a promise, and promises depend on everyone keeping them. What clients want to know is harder: what will the system itself allow, and what will it refuse to allow, even when someone makes a mistake?

The shift is easy to see in the paperwork. Five years ago, a client security review might have been a page of yes-or-no attestations. Now it is a detailed questionnaire, often the same one a client sends its software vendors, asking who can access a matter, how access is logged, what happens to the data when an engagement ends, and how the firm would even know if something went wrong. Those questions do not have good answers at the level of policy. They have answers at the level of architecture, or they do not have answers at all.

At SLW the answer is, trust is engineered, not asserted. Governance is a property of the architecture, and it is the same property across every tool in SLW Labs: ARTY, which is in production today, SimProf, and SILO. A brief orientation for anyone new here: SLW Labs is the firm’s in-house innovation platform, and its tools are held to one security posture rather than each inventing its own.

That posture has a few load-bearing parts. Identity is enterprise-grade access run through the firm’s single sign-on, so there are no side doors and no shadow accounts. Access is scoped to the authenticated person, so an attorney sees the matters they are entitled to see and nothing more. Client work is isolated by matter, so one client’s documents are invisible to anyone with no business to access them. Every meaningful action: a document opened, an AI interaction, is written to an audit log the firm keeps for years. None of that is a feature we advertise.

Audit logging deserves a word, because it is the part that sounds dull, but matters most. The value is not the log. The value is that the firm can answer a question after the fact with evidence. There is no reason to speculate or wonder who opened this matter, when, or if an AI tool was involved. When a client asks, it is the difference is between having a solid answer and keeping their relationship versus hoping for it and having to explain yourself.

Two rules are absolute. First, a human attorney reviews every piece of AI-assisted work product before anyone relies on it, which means no tool files anything on its own. Second, no client data enters a public AI model without authorization. The firm aligns this program with the NIST AI Risk Management Framework, not as a badge to wear, but because a shared vocabulary for risk is genuinely useful when a client’s own auditors come asking.

The human-review rule is the one we are least willing to soften, because it is where the profession’s obligations live. A tool can draft, suggest, retrieve, and flag. It cannot be the one who decides, and it cannot be the one who signs. Every piece of AI-assisted work at the firm passes under an attorney’s judgment before it counts. That is not a limitation, it is essential.

SILO sharpens why this matters, because SILO holds the documents. For a system whose entire job is to know what a matter is, isolation by matter cannot be a setting anyone can switch off. It has to be the foundation, built in from the first line rather than added once it already running. That is the standard SILO is being held to, and it is a large part of why a document layer was not something the firm was willing to rent.

The test we use is simple: can each claim here be shown rather than said? Identity, access scoping, isolation, logging, review: these are things a client’s own technical people can be walked through. Anything that cannot survive that walk-through does not belong in a piece like this one.

“I get asked to summarize our security for client questionnaires constantly, and the honest summary is short. A client’s matter should be invisible to everyone who has no business seeing it, and the system should enforce that even when a person makes a mistake, because people make mistakes. Most of my job making sure this remains true as we build and adopt new tools. It is easy to say and hard to keep, and SILO is the newest test of it.” -Anup Suresh, Principal, Data Security Officer, SLW

Clients are right to stop accepting assurances, and the firms worth working with will answer that with architecture rather than adjectives. In the final article of this series, Andre Marais steps back from the individual tools to where all of this is heading.

Learn more about SLW Labs.