Who Owns Security at AIL?
Drake Griffith is AIL's co-founder, CTO and Head of Security. He leads the technical direction of the studio and its security approach together, so decisions about permissions, integrations, and AI behavior belong in the engineering work from the start of a project.
Security decisions change what a system should be allowed to do. They affect which data enters a model, which integrations an assistant can reach, and when a person needs to take over. Putting that responsibility beside engineering gives the work a named owner. You can meet Drake and Zach Kellman, our co-founder and CEO, on the About page.
This article describes our approach through controls present in our website-assistant code and development practices. A project's final configuration depends on its data, users, and scope. The useful question in a security conversation is which controls protect a particular workflow and how those controls will be checked.
What Can an AI Assistant Actually Do?
We begin with the job the assistant needs to perform and limit its available tools to that job. A website assistant that answers questions and captures a lead does not need a general command runner, unrestricted database access, or permission to change unrelated business records.
In our website-assistant implementation, the model has one defined lead-capture tool. Application code handles the integration. That keeps the available action surface narrow: answering a question does not give the assistant every permission held by the business behind it. Even a small write capability deserves validation because a bad submission can still create unwanted records.
OWASP describes excessive agency as a risk when an AI system receives more functionality, permissions, or autonomy than it needs. For each build, we ask what the assistant needs to read, what it needs to change, and which decisions should remain with a person. Those answers shape the integration.
How Do We Protect the Connection to the Model?
Model and integration credentials stay on the server in the assistant architecture we build. Requests pass through application controls before reaching the model, including origin checks, signed session validation, and rate limits. A public chat interface is an entry point into a controlled backend.
The browser calls our application endpoints. The backend validates the session and applies request limits before doing model work. Origin checks are one layer; they are paired with session and abuse controls. Putting a secret into browser code would bypass that separation, so the widget does not call the model provider using a private key.
We also keep conversation history on the server for this assistant. The backend takes the new message and loads its own stored history instead of accepting a browser-supplied conversation as authoritative. That reduces the opportunity to fabricate earlier messages. Access checks belong in code because instructions to a model cannot authenticate a request.
How Do We Handle Prompt Injection and Unreliable Answers?
Our assistant combines input screening, a separate classifier, retrieval from a business knowledge base, and checks on the generated reply. Each layer has a limited job. These controls reduce risk, while restricted tools and server-side permissions limit what can happen if the model still responds incorrectly.
Input screening catches known attack patterns. A separate classifier checks whether a message belongs in the assistant's scope before the answer model runs. Retrieved business content supplies the material for an answer, and an output filter checks for signs of instruction leakage. When classification fails or usable context is missing, the code routes to a predefined response.
Grounding an answer in documents helps with relevance, but it does not make those documents trustworthy instructions. OWASP's prompt-injection guidance explains that retrieval alone does not eliminate the problem. We treat model behavior as fallible and keep access boundaries outside the model. No filter justifies giving a public assistant broad administrative powers.
How Do We Limit Abuse, Usage, and Unnecessary Data?
Our assistant code includes message limits, input-size checks, a session question limit, and a configurable daily model-usage budget. These controls bound how much work a public endpoint can trigger. Data handling is a separate design decision covering conversation storage, lead capture, and optional visitor tracking.
The budget mechanism reserves capacity before model work and reconciles recorded usage afterward. Its protection depends on a finite budget being configured, so the existence of a budget function is not enough by itself. Limits and fallback behavior need to match the deployment. When a session reaches its question limit, the assistant directs the visitor to the team.
We also separate chat functionality from optional visitor tracking in the widget. The tracking bridge checks consent before loading. A conversation can still contain personal information, and a captured lead may include conversation context in the CRM. Temporary chat storage and a CRM record have different lifetimes; requirements for both belong in project scoping.
| Boundary | Control in our assistant implementation |
|---|---|
| Access to the model | Server-side credentials and validated sessions |
| Available actions | A narrowly defined lead-capture tool |
| Model behavior | Input screening, classification, grounding, and output checks |
| Resource use | Rate limits, question limits, and a configurable usage budget |
How Do We Check That the Boundaries Hold?
Verification needs to exercise rejection paths as well as successful conversations. Our assistant repository includes adversarial smoke checks for invalid sessions, disallowed origins, off-topic requests, injection attempts, oversized input, and rate limits. These checks make expected behavior explicit and give engineering a repeatable starting point for review.
The repository also provides a budget-exhaustion test mode. A test file describes what should be checked; a passing run provides evidence about the version and configuration actually tested. That distinction matters whenever a model, integration, or setting changes. Our harness-engineering work follows the same principle: define observable behavior and verify it.
For your project, the conversation starts with the data involved and the consequences of an incorrect action. We use that scope to discuss access, approvals, fallback behavior, and verification. Bring us the workflow, and we can work through those decisions with you before expanding what the system is allowed to do.
