ArchitectShape

Security judgment the moment you need it.

Architect puts expert security judgment inside the coding agent you already use—powered by Inference Brain and grounded in the decision, stack, and constraints in front of you.

Security decisions get made by whoever is in the room.

Usually, that is no one whose job is security. The threat surface is enormous, guidance is scattered, and even careful engineers end up with blind spots.

Coding agents inherit the same problem: strong general reasoning without security judgment reliably present in the moment a decision is made.

Solo and lean teamsNo security architect on staff
Product engineeringCentral expertise is a queue away
Coding agentsReasoning without a security authority

A decision record, not a generic answer.

Architect combines your coding agent’s frontier reasoning with Inference Brain’s maintained security knowledge. It binds that judgment to the actual stack, versions, trust boundaries, and decision in front of you.

The result must explain what to do, why it applies here, and how you will know the implementation holds.

Example decision / tenant ownershipDecision → implementation → verification

Illustrative example. Shows the intended workflow, not a final product screen or a recorded run.

Recommendation

Bind principal and organization ownership in the database policy. Treat route checks as defense in depth.

Object identity is not ownership. A route-only check protects one call path; the database policy protects callers subject to it. Privileged workers that bypass row policy must independently bind the originating organization at the data operation.

Implementation consequence

- .eq("id", invoiceId)
+ .eq("id", invoiceId)
+ .eq("organization_id", principal.orgId)

CREATE POLICY invoice_owner_read
ON invoices FOR SELECT
USING (
  organization_id = current_org_id()
);

Assumes row-level security is enabled, current_org_id() derives from verified organization membership, and the application role cannot bypass row policy. Privileged workers require separate controls.

Illustrative verification outcomes

  • PassOwner can retrieve an invoice in the active organization.
  • PassCross-tenant invoice ID returns no row through the API route.
  • PassCross-tenant invoice ID returns no row through the background export.
  • PassDirect reads by the application’s unprivileged role remain tenant-scoped.

These checks illustrate how the decision would be verified. Repository-wide path discovery remains Scanner’s job.

Ask at the moment the answer can still change the system.

No ticket, meeting, or separate dashboard. Invoke Architect in the coding session with the security decision in front of you.

  1. 01Name the decision

    Ask in plain language or technical detail. Architect identifies the security question beneath it.

  2. 02Bind the context

    Stack, versions, data, identities, trust boundaries, and constraints determine what advice applies.

  3. 03Reason with Brain

    Inference Brain supplies applicable security guidance, rationale, and source provenance.

  4. 04Return a testable decision

    A recommendation with implementation direction, rationale, and concrete verification steps.

DesigningSecond opinion before you build it.
BuildingFirst-principles guidance while you write it.
ReviewingA check before you move on.

Three products. One security model carried forward.

01 / ShapeArchitect

Shape security-sensitive decisions while building.

 02 / InvestigateScanner

Investigate system-level risk across the codebase.

 03 / WatchSentry

Watch deployed posture as the system changes.

Security judgment inside the work.

Bring expert security judgment into the decisions that shape the system.