Generate an internal tool that won't fail your next SOC 2 audit

What you get in the generated ZIP

A typical internal-tool generation includes:

app/blueprints/
├── auth_bp.py                # JWT + step-up auth for sensitive routes
├── role_bp.py                # role + permission management
├── audit_log_bp.py           # immutable, append-only
├── user_bp.py                # admin user management
├── customer_lookup_bp.py     # support-tool customer search
├── action_bp.py              # generic action handler with audit hook
└── feature_flag_bp.py        # toggle features per environment

app/models/
├── role.py                   # name, description
├── permission.py             # resource + action grants
├── role_permission.py        # M:N
├── user_role.py              # user assignment
└── audit_log.py              # actor, action, resource, before/after, IP, timestamp

What's already wired

• Role-based access control: explicit roles (admin, support, finance, viewer) with explicit permissions per resource. No implicit superadmin. The decorator @requires_permission("invoice.refund") enforces at route entry.
• Step-up auth: routes flagged as sensitive (issue refund, delete customer, change role) require recent re-authentication. Default window: 5 minutes.
• Audit log: every state-changing action writes a row with actor, action, resource ID, before/after JSON, IP, user agent, timestamp. Append-only — no row in this table is ever updated or deleted.
• Customer lookup: support-tool search with masked PII by default; full PII reveal requires step-up + audit-logged "reveal" action.
• Feature flags: per-environment toggles with audit log on every change. Useful for "killswitch" patterns during incidents.
• 2FA: TOTP-based 2FA on internal users by default; SMS optional via Twilio.
• Session management: admin can revoke any user's sessions; users can see their own active sessions.

What ships in docs/

• docs/security/posture.md — full RBAC + audit + step-up architecture
• docs/compliance/soc2-controls.md — §CC6 (logical access) and §CC7 (system operations) controls matrix populated from the permission model
• docs/decisions/ADR-0008-rbac-model.md — role + permission vs ABAC, with rejected alternatives
• docs/decisions/ADR-0011-audit-log-immutability.md — append-only table, optional WORM storage for higher-tier audits

Internal links

• for/cto and for/engineering-manager cover the audit-readiness angle
• Sentry integration for error tracking on the internal tool

CTA

Try it — free plan, no credit card. archiet.com.

Generate an internal tool, look at the audit log shape and the RBAC, decide if it's the kind of evidence package your auditor would accept.