How Isolation Is Enforced
The standard answer to automated code authorship is to let it write and then govern the output: approvals, permissions, scans, an audit trail. Those are real controls with a real cost, and the cost scales with the volume of change, which is exactly the thing an assistant increases. The approach here is to remove the reach first and review the change second.
An API key names exactly one tenant and cannot be pointed at another. Isolation is a property of the credential rather than a rule something is asked to follow, so a confused, misled, or compromised client still cannot address a tenant its key does not name. There is no parameter that widens the scope.
Every write goes through a single validated entry point regardless of where it came from. Automated writes are not admitted through a side door with lighter checks, which means there is one set of checks to reason about and audit rather than two that can drift apart.
Every edit runs as a dry run first and returns the exact byte delta before anything is written. Review happens on the change itself, at function granularity, rather than on a regenerated file that has to be compared against what was there before.
Production is deliberately unreachable from the MCP server. There is no permission to misconfigure, because the path does not exist. Promoting work to production runs through one gated path that moves code, schema, shortcuts and users together, so nothing arrives half-promoted and no piece is left behind.
“Inspection trusts the reviewer to catch what the model did. Prohibition removes the reach, then shows you the delta anyway.”
What A Reviewer Should Ask
These are the questions we would ask in your position, with the answers we can give today.
Where does the application live?
Page code, Python, schema and desktop shortcuts are records in Azure SQL, resolved at call time. There is no build artifact and no deployed bundle, so the surface to inventory is the database rather than a fleet of releases.
What can an assistant reach?
The tenant its key names, and nothing else. Thirteen tools, all scoped to that tenant, covering discovery, authoring, editing, schema and desktop placement. Production is not among them.
What stops a bad change landing?
The validated entry point applies to every write, and the dry run puts the exact byte delta in front of a human before the write happens. Saves are inserts rather than overwrites, so the prior version remains in the store.
Can this run inside our boundary?
Yes. A self-hosted mode puts the runtime inside your own environment, which is the relevant answer when the constraint is data residency rather than change velocity. The three modes.
Where We Are Today
Frames Studio is early and built by a small team. Several artifacts that a mature vendor security review expects are not in place yet, and we would rather you learn that here than four weeks into an evaluation.
We do not have a SOC 2 report. We have not published an independent third-party audit, a penetration test summary, or a completed buyer security questionnaire. There is no published data processing addendum or subprocessor list yet, and no published single sign-on claim. None of those are things we intend to imply by omission.
What we do have is the architecture described above, a self-hosted option for teams whose constraint is where the data sits, and a willingness to answer a specific question with a specific answer. If your review needs an artifact, tell us which one and we will tell you honestly whether it exists, when it will, or that it does not.
If a hosted multi-tenant service cannot clear your process as it stands today, that is a reasonable conclusion to reach, and the self-hosted path is the conversation worth having instead.