Arist builds frontier AI systems that help enterprise leaders deeply understand their organization, find what’s blocking excellence, and make the right decision. Its AI agents interview employees, analyze internal company data and coordinate responses. That work requires access to sensitive company data, and customers want to know how it stays protected.
Consider a single file upload. A customer sends a document to Arist. Its contents pass through a parser, enter a model’s context and can influence actions an agent then takes on the customer’s behalf. At each step, the system has to decide exactly what that content is allowed to do.
Agents acting with customer context have changed how Arist thinks about security:
“Our threat model has changed from ‘what can a user send us?’ to ‘what can a user get the system to do?’ Customer content can influence what a model produces and what an agent does next. We have to account for both. An output steered by hostile content is a security problem even if no customer data leaves the system.”
– Mike Doty, Director of Platform Engineering at Arist
Enterprise buyers now ask:
- How do you keep our data isolated from other customers’ data throughout an AI workflow?
- What customer content reaches each model?
- How do you test the actions agents can take on our behalf?
Arist has to explain how those boundaries are enforced and tested throughout the path from customer input to system action.
Protecting the Path from Input to Action
Content from many organizations moves through the same infrastructure, so tenant isolation comes first. Every intermediate artifact and cache must remain scoped to the organization that owns it. That boundary has to hold throughout processing, including stages the customer never sees.
“Parsing untrusted files is expensive, and that work runs on infrastructure that other customers depend on. An input that makes the system do far more work than it should can affect everyone sharing that capacity. Bounding what untrusted content can make the system do ends up being most of the day-to-day work.”
– Mike Doty, Director of Platform Engineering at Arist
The same discipline governs the model. Arist treats prompt injection through customer content as a real threat and constrains what reaches the model. As agents take actions, the permissions behind those actions matter as much as confidentiality.
None of this replaces the application's existing responsibilities: protecting user data, enforcing roles and permissions, and safeguarding credentials and cloud metadata.
Every pull request goes through static analysis, dependency scanning and automated review from several perspectives, including security. Findings are verified before posting, changes are scored for risk and sensitive or unresolved issues go to a human. SOC 2 controls, periodic access reviews and third-party penetration testing surround that workflow.
Continuous Analysis Through a Changing Architecture
Arist also needs analysis that follows the whole system as its architecture changes.
“Octane fills the gap between fast CI checks and deep annual assessments. When we adapted our existing AI services into a shared document pipeline for enterprise content, the analysis ran throughout that development. It kept looking as the code changed. That matters because a finding can depend on how several parts of a service work together across an entire workflow.”
– Mike Doty, Director of Platform Engineering at Arist
Octane continuously analyzes Arist’s repositories as the code changes. It traces execution paths and interactions across the codebase to identify vulnerabilities that depend on how different parts of the system work together.
Arist reports that Octane occasionally surfaces issues that require understanding an entire workflow, past the point where its own scanners stop. On more common findings, Octane overlaps with those scanners and with internal review. The team wants that overlap: its program deliberately points several systems at the same code, each time having another chance to catch a problem.
The findings feed directly into development.
“Octane’s findings land in our issue tracker for an engineer to evaluate, alongside the rest of our development work. Engineers decide what needs to change and retain control over the code we merge. Having findings arrive in the normal engineering queue means security work gets done in normal sprints instead of as a separate event.”
– Mike Doty, Director of Platform Engineering at Arist
Onions, Not Eggshells
Arist’s approach to security rests on an assumption about how defenses fail:
“Onion, not eggshell. An eggshell is hard until it cracks, and then there’s nothing behind it. We assume any single layer will eventually miss something, so we build other defenses around it. We want overlap between our own review, automated analysis and independent penetration testing.”
– Mike Doty, Director of Platform Engineering at Arist
.jpg)
Each layer contributes something different. Automated analysis provides breadth and speed. Compliance assessments evaluate the processes and controls around that work. And Arist also engages Octane for penetration testing. Its compliance requirements call for an independent third party and a signed report; automated analysis alone does not satisfy those requirements.
“None of these layers substitutes for the others. We’d rather a customer understand how those defenses work together than believe one tool makes a product secure.”
– Mike Doty, Director of Platform Engineering at Arist
Schedule a demo to see how Octane’s continuous offensive security fits into your development workflow.
Subscribe to our newsletter
