[{"data":1,"prerenderedAt":37},["ShallowReactive",2],{"blog-tag-api-first":3},[4,24],{"id":5,"slug":6,"body":7,"html":8,"title":9,"description":10,"category":11,"tags":12,"author":17,"date":18,"year":19,"month":20,"quarter":21,"status":22,"featured":23},"2026\u002F07\u002Ffactory-and-architecture\u002Fidentity-tenancy-and-authorization-from-the-first-commit","identity-tenancy-and-authorization-from-the-first-commit","\nAsk what usually delays an AI application's go-live and the answer is rarely the AI. It's the security review. Specifically, the discovery that identity was bolted on, authorization checks are scattered through the code, and tenant isolation depends on every developer remembering a `where` clause.\n\nIn our factory, these three concerns are part of the architecture from the first commit. They're generated into the core of every application foundation.\n\n## Identity\n\nEvery foundation authenticates against an **enterprise identity provider** from day one: OpenID Connect or SAML to Entra ID, Okta, Ping, government SSO or a national identity platform. Local development uses the same flows with a local provider. There's no “temporary” username and password table waiting to be removed.\n\nService-to-service calls use their own identities, and AI agents act either as a service identity or on behalf of the invoking user, never with ambient superuser rights.\n\n## Authorization\n\nAuthorization is **explicit and central**:\n\n- Roles map to permissions in one place.\n- Permissions are checked in the application services layer, not in route handlers or UI code. Every entry point gets the same checks: the API, background jobs, agents and imports.\n- Consequential actions can require a second approver (maker\u002Fchecker) as a declared policy, not ad-hoc code.\n- Principals are re-evaluated per request, so a disabled user or a changed role takes effect immediately.\n\nThis is what makes a security review short. Reviewers read one policy map instead of hunting through handlers.\n\n## Multi-tenancy\n\nMany applications serve several tenants: business units, subsidiaries, government entities, partners, or customers of an SI. The foundations treat the **tenant as a first-class part of the data model**:\n\n- Tenant-owned records are stored and queried within the tenant's partition.\n- The tenant is taken from the authenticated principal, never from request data. A forged tenant ID in a payload is ignored.\n- Cross-tenant requests return “not found” rather than “forbidden”, so they don't leak existence.\n- Cross-tenant views, where legitimately needed, are separate and permissioned paths.\n\nIsolation is tested automatically: cross-tenant reads and writes are part of every foundation's test suite.\n\n## Why generate it instead of documenting it\n\nA guideline that says “always check the tenant” is followed until the deadline. A generated core that makes the unsafe path hard is followed every time. Because the same patterns run across the whole inventory, a weakness found in one place gets fixed in the factory and flows into every foundation that follows.\n\n## What still happens per customer\n\nThe integration with the customer's identity provider and directory, their role model and approval policies, their tenancy boundaries, and their security review. The rails are fixed, and the configuration is the customer's.\n\nMore on the rails: [Architecture](\u002Ffactory\u002Farchitecture) · [AI accelerates, architecture governs](\u002Fblog\u002Fai-accelerates-architecture-governs)\n","\u003Cp>Ask what usually delays an AI application's go-live and the answer is rarely the AI. It's the security review. Specifically, the discovery that identity was bolted on, authorization checks are scattered through the code, and tenant isolation depends on every developer remembering a \u003Ccode>where\u003C\u002Fcode> clause.\u003C\u002Fp>\n\u003Cp>In our factory, these three concerns are part of the architecture from the first commit. They're generated into the core of every application foundation.\u003C\u002Fp>\n\u003Ch2>Identity\u003C\u002Fh2>\n\u003Cp>Every foundation authenticates against an \u003Cstrong>enterprise identity provider\u003C\u002Fstrong> from day one: OpenID Connect or SAML to Entra ID, Okta, Ping, government SSO or a national identity platform. Local development uses the same flows with a local provider. There's no “temporary” username and password table waiting to be removed.\u003C\u002Fp>\n\u003Cp>Service-to-service calls use their own identities, and AI agents act either as a service identity or on behalf of the invoking user, never with ambient superuser rights.\u003C\u002Fp>\n\u003Ch2>Authorization\u003C\u002Fh2>\n\u003Cp>Authorization is \u003Cstrong>explicit and central\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Roles map to permissions in one place.\u003C\u002Fli>\n\u003Cli>Permissions are checked in the application services layer, not in route handlers or UI code. Every entry point gets the same checks: the API, background jobs, agents and imports.\u003C\u002Fli>\n\u003Cli>Consequential actions can require a second approver (maker\u002Fchecker) as a declared policy, not ad-hoc code.\u003C\u002Fli>\n\u003Cli>Principals are re-evaluated per request, so a disabled user or a changed role takes effect immediately.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This is what makes a security review short. Reviewers read one policy map instead of hunting through handlers.\u003C\u002Fp>\n\u003Ch2>Multi-tenancy\u003C\u002Fh2>\n\u003Cp>Many applications serve several tenants: business units, subsidiaries, government entities, partners, or customers of an SI. The foundations treat the \u003Cstrong>tenant as a first-class part of the data model\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Tenant-owned records are stored and queried within the tenant's partition.\u003C\u002Fli>\n\u003Cli>The tenant is taken from the authenticated principal, never from request data. A forged tenant ID in a payload is ignored.\u003C\u002Fli>\n\u003Cli>Cross-tenant requests return “not found” rather than “forbidden”, so they don't leak existence.\u003C\u002Fli>\n\u003Cli>Cross-tenant views, where legitimately needed, are separate and permissioned paths.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Isolation is tested automatically: cross-tenant reads and writes are part of every foundation's test suite.\u003C\u002Fp>\n\u003Ch2>Why generate it instead of documenting it\u003C\u002Fh2>\n\u003Cp>A guideline that says “always check the tenant” is followed until the deadline. A generated core that makes the unsafe path hard is followed every time. Because the same patterns run across the whole inventory, a weakness found in one place gets fixed in the factory and flows into every foundation that follows.\u003C\u002Fp>\n\u003Ch2>What still happens per customer\u003C\u002Fh2>\n\u003Cp>The integration with the customer's identity provider and directory, their role model and approval policies, their tenancy boundaries, and their security review. The rails are fixed, and the configuration is the customer's.\u003C\u002Fp>\n\u003Cp>More on the rails: \u003Ca href=\"\u002Ffactory\u002Farchitecture\">Architecture\u003C\u002Fa> · \u003Ca href=\"\u002Fblog\u002Fai-accelerates-architecture-governs\">AI accelerates, architecture governs\u003C\u002Fa>\u003C\u002Fp>\n","Identity, tenancy and authorization from the first commit","Why identity, multi-tenancy and authorization are generated into the core of every fazeZERO application foundation instead of added before go-live.","factory-and-architecture",[13,14,15,16],"identity","architecture","application-factory","api-first","fazezero-editorial","2026-07-29T00:00:00.000Z",2026,7,3,"published",false,{"id":25,"slug":26,"body":27,"html":28,"title":29,"description":30,"category":11,"tags":31,"author":17,"date":33,"year":19,"month":34,"quarter":35,"status":22,"featured":23,"series":36,"seriesOrder":21},"2026\u002F06\u002Ffactory-and-architecture\u002Fcoding-assistants-are-not-an-architecture","coding-assistants-are-not-an-architecture","\nIt is the most common objection we hear from enterprises and systems integrators, and it's a fair one:\n\n> “Our developers already use Cursor, Claude Code and Copilot. Why do we need you?”\n\nThe honest answer is **not** that we have better AI. We use the same class of tools. The difference is what those tools are pointed at.\n\n## Implementation engines\n\nAI coding assistants are extraordinary at implementation. Given a clear intent and a clear structure, they write correct code quickly, refactor fluently and generate tests on request. They make good engineers much faster.\n\nWhat they don't provide is the structure itself. A general-purpose assistant has no opinion about your bounded contexts, your API versioning policy, your tenancy model or how your adapters should isolate a core banking system. It will happily produce *an* answer every time. It will not reliably produce the *same* answer every time.\n\n## Where the risk accumulates\n\nThe risks of architecture-free AI development are predictable:\n\n- **Inconsistent domain boundaries.** The same business concept lives in three services, modelled three ways.\n- **Weak API design.** Endpoints shaped by screens rather than contracts, and no versioning discipline.\n- **Late identity and authorization.** Role checks scattered through handlers, added after the demo.\n- **Inconsistent multi-tenancy.** Tenant isolation handled by convention, differently in each module.\n- **Thin testing.** Tests written to pass rather than to specify.\n- **Drift.** Regenerating a module quietly changes behaviour elsewhere.\n- **Production rework.** The prototype gets rewritten the moment it meets security review, integration or scale.\n\nNone of this is the tool's fault. It's what happens when the architecture is left to emerge.\n\n## An architectural system\n\nfazeZERO provides the part the assistants lack: a reusable application architecture refined over roughly two years and exercised across hundreds of application foundations. Concretely:\n\n- **Domain-Driven Design** with bounded contexts as the unit of structure\n- **OpenAPI-first contracts** validated before implementation\n- **Identity, authorization and multi-tenancy** generated into the core\n- **Adapters** that keep integrations out of the domain\n- **Testing and AI evaluation** as a delivery gate\n- **Observability, audit and evidence** patterns shared by every application\n- **Controlled regeneration**, so generated code can be refreshed without losing customer logic\n\nThe assistants then do what they are good at, inside those rails. We call it simply: **AI accelerates the implementation. fazeZERO governs the architecture.**\n\n## What this means for a systems integrator\n\nFor an SI, the question is not “fazeZERO or our developers.” It's whether every engagement should start with a blank repository and a fresh architecture debate. A reusable application layer means:\n\n- proposals start from an existing foundation and a defined delta\n- less pre-sales engineering on every opportunity\n- the SI's developers use their AI tools on customer-specific work, not on reinventing the plumbing\n\nWe describe the partner model in [how systems integrators can industrialize AI delivery](\u002Fblog\u002Fhow-systems-integrators-industrialize-ai-delivery).\n\n## A simple test\n\nAsk your team to build the same small application twice, a week apart, with the same assistant and the same requirements. Then compare the two architectures. If they differ in ways that would matter in production, you have found the gap an architectural system fills.\n\nSee the rails in detail on the [Architecture](\u002Ffactory\u002Farchitecture) page, or [bring us a use case](\u002Fcontact) and we'll show you the delta against the closest foundation.\n","\u003Cp>It is the most common objection we hear from enterprises and systems integrators, and it's a fair one:\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>“Our developers already use Cursor, Claude Code and Copilot. Why do we need you?”\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>The honest answer is \u003Cstrong>not\u003C\u002Fstrong> that we have better AI. We use the same class of tools. The difference is what those tools are pointed at.\u003C\u002Fp>\n\u003Ch2>Implementation engines\u003C\u002Fh2>\n\u003Cp>AI coding assistants are extraordinary at implementation. Given a clear intent and a clear structure, they write correct code quickly, refactor fluently and generate tests on request. They make good engineers much faster.\u003C\u002Fp>\n\u003Cp>What they don't provide is the structure itself. A general-purpose assistant has no opinion about your bounded contexts, your API versioning policy, your tenancy model or how your adapters should isolate a core banking system. It will happily produce \u003Cem>an\u003C\u002Fem> answer every time. It will not reliably produce the \u003Cem>same\u003C\u002Fem> answer every time.\u003C\u002Fp>\n\u003Ch2>Where the risk accumulates\u003C\u002Fh2>\n\u003Cp>The risks of architecture-free AI development are predictable:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Inconsistent domain boundaries.\u003C\u002Fstrong> The same business concept lives in three services, modelled three ways.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Weak API design.\u003C\u002Fstrong> Endpoints shaped by screens rather than contracts, and no versioning discipline.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Late identity and authorization.\u003C\u002Fstrong> Role checks scattered through handlers, added after the demo.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Inconsistent multi-tenancy.\u003C\u002Fstrong> Tenant isolation handled by convention, differently in each module.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Thin testing.\u003C\u002Fstrong> Tests written to pass rather than to specify.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Drift.\u003C\u002Fstrong> Regenerating a module quietly changes behaviour elsewhere.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Production rework.\u003C\u002Fstrong> The prototype gets rewritten the moment it meets security review, integration or scale.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>None of this is the tool's fault. It's what happens when the architecture is left to emerge.\u003C\u002Fp>\n\u003Ch2>An architectural system\u003C\u002Fh2>\n\u003Cp>fazeZERO provides the part the assistants lack: a reusable application architecture refined over roughly two years and exercised across hundreds of application foundations. Concretely:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Domain-Driven Design\u003C\u002Fstrong> with bounded contexts as the unit of structure\u003C\u002Fli>\n\u003Cli>\u003Cstrong>OpenAPI-first contracts\u003C\u002Fstrong> validated before implementation\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Identity, authorization and multi-tenancy\u003C\u002Fstrong> generated into the core\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Adapters\u003C\u002Fstrong> that keep integrations out of the domain\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Testing and AI evaluation\u003C\u002Fstrong> as a delivery gate\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Observability, audit and evidence\u003C\u002Fstrong> patterns shared by every application\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Controlled regeneration\u003C\u002Fstrong>, so generated code can be refreshed without losing customer logic\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>The assistants then do what they are good at, inside those rails. We call it simply: \u003Cstrong>AI accelerates the implementation. fazeZERO governs the architecture.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2>What this means for a systems integrator\u003C\u002Fh2>\n\u003Cp>For an SI, the question is not “fazeZERO or our developers.” It's whether every engagement should start with a blank repository and a fresh architecture debate. A reusable application layer means:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>proposals start from an existing foundation and a defined delta\u003C\u002Fli>\n\u003Cli>less pre-sales engineering on every opportunity\u003C\u002Fli>\n\u003Cli>the SI's developers use their AI tools on customer-specific work, not on reinventing the plumbing\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>We describe the partner model in \u003Ca href=\"\u002Fblog\u002Fhow-systems-integrators-industrialize-ai-delivery\">how systems integrators can industrialize AI delivery\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>A simple test\u003C\u002Fh2>\n\u003Cp>Ask your team to build the same small application twice, a week apart, with the same assistant and the same requirements. Then compare the two architectures. If they differ in ways that would matter in production, you have found the gap an architectural system fills.\u003C\u002Fp>\n\u003Cp>See the rails in detail on the \u003Ca href=\"\u002Ffactory\u002Farchitecture\">Architecture\u003C\u002Fa> page, or \u003Ca href=\"\u002Fcontact\">bring us a use case\u003C\u002Fa> and we'll show you the delta against the closest foundation.\u003C\u002Fp>\n","Cursor, Claude Code and Copilot are implementation engines, not architectures","Our developers already have AI coding tools, so why use fazeZERO? The answer is not better AI. It is the architectural system the AI works inside.",[14,15,16,32],"production","2026-06-23T00:00:00.000Z",6,2,"the-application-factory",1790080513466]