AI NativeSecurity Architect

Make sure AI is not a way around your access rules

Agents authorized at the same gateway, with the same roles and the same scoping as people

Make sure AI is not a way around your access rules

The question a security architect asks about any AI feature is short: does this create a path to data that the permission model would otherwise refuse? It is the right question, and for a governed data platform it is the only one that really matters, because a federation layer is by definition pointed at everything valuable a company has.

SemanticFed's answer is structural rather than promissory. Authorization happens at the workspace API gateway, and every operation in the federation surface — reading a model, authoring an entity, publishing a query, executing a run, toggling a policy — carries an explicit action, resource, and scope that the gateway enforces from the composed schema. Services never validate tokens themselves; identity arrives as verified context. Because there is one enforcement point rather than one per caller type, an agent is not a new kind of client with its own rules. It is a caller with an identity, subject to the same checks.

That is why the shipped MCP server needed no parallel permission system: it calls the same gateway with the caller's own identity, and every write is additionally scoped to the calling workspace in the service layer, so an identifier guessed from another tenant does not resolve. It is also why the planned natural-language and autonomous layers are specified to hold no privileged route to data — an AI-authored query is designed to be an ordinary query that hits the same policy path, such that a restricted user gets identical results whether the query was written by them or generated for them.

Two gaps are worth stating plainly rather than glossing. First, the agent tool surface does not yet gate its irreversible operations behind an explicit confirmation step; deleting a modelled entity or archiving a published model is currently as easy for an agent as reading one, and closing that is active work. Second, the assistant experience inside the app is not wired yet — the in-app AI page is a placeholder today, and the shared assistant integration is still to come. Both are tracked, and neither is presented here as done.

Pre-launch product. The authorization architecture described is real and code-verified; the AI surfaces that will inherit it are at the stages stated above.

This is an authorization-architecture story, not a standalone web UI walkthrough. The guarantees are enforced by the gateway on every click and every agent call, so there is no separate "Do it yourself" web flow for it.

Ready to make this your story?