Production systems may use enterprise identity, application login, API authentication or a dedicated service identity according to the customer environment. Backend checks—not interface visibility—should enforce role behaviour.
Security & Governance
Controls belong around the model.
Finch Island treats AI as one component inside a broader application architecture. Authentication, permissions, business rules, approval and system access should be enforced outside the model wherever practical.
This page is an architectural starting point—not a replacement for a customer-specific security review.- 01UserRequest context↓
- 02AuthenticationVerify identity↓
- 03Role / permissionsDetermine allowed scope↓
- 04Application / workflowOrchestrate the task↓
- 05Validation & rulesEnforce conditions↓
- 06AI / data / toolsUse only approved capability↓
- 07Human approvalKeep judgment explicit↓
- 08ActionExecute permitted change↓
- 09Audit / monitoringRecord and observe
Control areas
Questions the architecture needs to answer.
- 01
Identity
Who is using the system?Production systems should know which user or service is making a request before deciding what information or actions are available.
A role selector in a public demo is not authentication. Production deployments should use the customer's real identity model. - 02
Least-Privilege Access
What does this workflow actually need?Give the workflow the minimum access necessary for its defined job. A workflow that reads two CRM fields should not receive permission to delete CRM records.
System-to-system workflows may use a dedicated service identity rather than a human user's unrestricted credentials. - 03
Data Boundaries
Which information can this user and workflow access?A knowledge assistant, document workflow or agent should receive only the information required for the task and access context.
Exclude first. Generate second. Hiding a record in the interface is not sufficient access control. - 04
Human Approval
Which decisions should remain with a person?Commercial commitments, financial actions, sensitive decisions and unusual exceptions can remain behind explicit approval gates.
The system prepares. A person decides. - 05
Validation & Business Rules
What must be true before the workflow continues?Model output should be treated like any other untrusted input before it changes business data or triggers an important action.
AI interprets. Rules enforce. Missing information should stop the workflow before it becomes a commercial mistake. - 06
Logging & Auditability
Can you see what happened?The application can record operational inputs, actions, approvals, outputs and workflow events so important steps are traceable.
Logging should avoid unnecessarily copying sensitive content into debug or monitoring systems. - 07
Model & Provider Boundaries
What is sent to the AI provider?The application should control the relevant context, chosen provider, available tools, output limits and data-handling configuration for the task.
Send what is needed for the task. Treat instructions inside user content or documents as data, not privileged system instructions. - 08
Monitoring & Failure Handling
What happens when something does not work?Provider outages, malformed output, permission denials and integration failures need visible exception paths with an owner.
Fail visibly, not silently. A model outage should become an exception, not a disappearing customer request.
Human-in-the-loop AI
Authority should match impact.
The same model output can require different controls depending on whether it searches, drafts, communicates externally or changes a business record.
ActionControl
Search approved documentsAutomatic
Extract RFQ requirementsAutomatic + validation
Prepare quotation draftAutomatic
Send quotationHuman approval
Update CRM activityAfter approval
Change pricing rulesAuthorised admin
Delete customer recordNot available
Deployment architecture
Application controls sit between the user, model and business systems.
Send only the relevant context for the task. Provider, model, tool access, retention configuration and storage controls are architecture decisions; encryption and data-location requirements depend on the deployment.
Inputs and model outputs are validated against structure, allowed values and business conditions. Important external, financial or sensitive actions can remain behind explicit approval.
Failures should be visible, assigned and recoverable. Retries must be safe for the operation; otherwise the work enters an exception or manual path instead of disappearing.
This website's public demos
Claims bounded by the implementation.
The public tools demonstrate narrow controls; they are not connected customer systems or authenticated enterprise deployments.
- Public demos are limited to narrow, defined tasks.
- Input and request-body sizes are bounded and validated server-side.
- Rate limits apply to public AI endpoints.
- Provider credentials remain in server-side code paths.
- AI responses are parsed against expected structured schemas.
- Demo tools do not receive arbitrary business-system or code-execution access.
- Visitors are warned not to submit confidential, personal or commercially sensitive information.
Document IntelligenceDocument → AI extraction → Schema validation → Human review
Enterprise KnowledgeDemo access profile → Permission filter → Retrieval → Answer + citations
Process AnalyserBounded text → Server validation → Structured analysis → Validated result
Change governance
A newer model is not automatically a better production change.
- 01Name the workflow owner and the people allowed to approve changes.
- 02Evaluate model, prompt, rule and integration changes against representative tests and known failure cases.
- 03Do not replace a production model simply because a newer model exists.
- 04Treat prompt, rule and integration changes as software changes when they can alter system behaviour.
- 05Define who reviews failures, source data and operational outcomes after release.
Customer-specific architecture
Start with what the system needs to see and do.
A project architecture review can map data flow, access, integration scopes, approvals and exception paths against the actual environment.