The boundaries that matter

Keep authority
where it belongs.

A practical design checklist for credentials, data access, generated proposals, and consequential actions.

What this website does

NeuralAPI.com serves static reading material and local reference examples. The Pattern Lab changes displayed JSON, copies text when you click a copy button, and reveals fixed example results. It does not accept a provider credential, send prompts to a model, execute tools, connect to a robot, or access a financial account.

The points below are design guidance for a separate application you may build. They are not a certification that a future integration is secure or appropriate for a particular use.

Keep credentials out of public code

Do not put a private provider key into browser-delivered JavaScript, HTML, a public repository, or an example request. In a real system, an application-controlled service should hold the credential and apply the user's permissions before calling a provider. Limit the credential to the capabilities the service actually needs.

Avoid logging secrets or copying them into diagnostic screenshots. A local prototype becomes public code as soon as it is published; moving a key into a separate browser configuration file does not make it private.

Check access before retrieving data

Apply the current user's permissions before a document or record reaches the model context. Do not retrieve broadly and depend on the assistant to hide protected details in its final answer. Account for cached material, changed permissions, and deleted source documents.

Treat retrieved passages and user-authored tool results as untrusted content. They may contain instructions, but those instructions do not change application policy or grant access to other records.

Separate a proposal from an action

Validate the exact operation

Check argument structure, user identity, target resource, allowed operation, and current state. A model-generated object that passes a schema may still be unauthorized or stale. Use narrow tools instead of unrestricted execution interfaces.

Confirm consequential changes

Show the exact target and proposed change when review is required. Bind approval to those details. Do not treat a general request for assistance as unlimited permission for later writes or a materially changed action.

Reconcile uncertain completion

A timeout does not prove that a write failed. Use the receiving system's supported status or idempotency mechanism to reconcile before repeating an operation. Report accepted, completed, rejected, and uncertain states honestly.

Limit work and make stopping explicit

Bound time, attempts, and tool calls. Explain what remains unfinished when a budget is exhausted. Physical systems need appropriate independent controller and stop behavior; a language-model conversation must not be their sole safeguard.

Minimize retained content

Prefer operational identifiers, configuration versions, durations, and validation outcomes over unrestricted copies of every prompt. Where diagnostic samples are justified, define access and retention. Consider derived summaries, exports, and caches—not only the main database.

Report a concern about this site

Email [email protected] with the affected page and a description that does not expose private credentials or personal information. Do not send secrets, exploit unrelated services, or include sensitive recordings. For an incident in a provider account, use that provider's official support and security channels.