Assessments & penetration testing.
Investigate weaknesses in applications, APIs, and AI systems, with evidence that explains impact, guides remediation, and supports targeted retesting.
- Clear priorities
- Useful evidence
- Practical next steps
Independent research. Enterprise security engineering.
Find what matters.
Know what holds.
Arquebus assesses complex systems, builds security tools and controls, and brings ongoing testing and remediation together through Allmind—on your team’s priorities and schedule.
Research-led. Evidence-grounded. Human-directed.Scroll to explore
Ways to work with usAssessments & pentestsCustom security toolingAllmind program
Three ways to work with Arquebus
Start with the decision
you need to make.
Understand where you are exposed, build a control that fits, or keep testing and remediation moving together.
Custom security tooling.
Design and build security tools, controls, and integrations around your environment—from testing workflows to the systems that support remediation.
- Security controls
- System integrations
- Custom engineering
Allmind.
A SaaS platform bringing ongoing security testing, patch management, and verification together. Powered by Ayre, with scope, priorities, and timing directed by your team.
- Ongoing testing
- Patch management
- Verification
How the work helps
From uncertainty
to a clear next step.
Technical depth should make a decision easier. We connect the evidence to what your team needs to do next.
- 01 / UNDERSTAND
See what matters.
Understand the exposure, the conditions behind it, and the limits of what is known.
- 02 / ACT
Choose a response.
Use the finding to prioritize a fix or control that fits your system and your constraints.
- 03 / VERIFY
Check what changed.
Retest the relevant behavior and make remaining questions visible to the team.
Allmind / Powered by Ayre
From a finding to what happens next.
Allmind is a SaaS platform bringing ongoing security testing, patch management, and verification together. Powered by Ayre, with scope, priorities, and timing directed by your team. Available to clients.
For a closer look
Selected examples
of our approach.
A closer look at the engineering behind an assessment, a custom control, and a testing and remediation cycle. Each illustrates one part of our wider practice.
Illustrative examples Fictional systems and outcomes, used to show the format and reasoning. These are not client findings or research claims.
01 / ASSESSMENTDo permissions hold across the whole workflow?Follow access from the application into a connected service and a background task.View exampleClose example
Fictional application workflowSynthetic recordsIllustrative assessment
Example finding / Connected accessIllustrative
An access change is enforced in one service but missed in another.
- Question
- Does the export workflow respect current permissions when work is requested, processed, and delivered?
- Observation
- In this fictional result, interactive access is denied after permission is revoked, while a previously queued export still delivers synthetic records.
- Comparison
- Compare a user with continuing access, a user whose access was revoked, and a user from another workspace.
- Impact
- The export exposes records after the user’s permission to receive them has ended.
- Fix direction
- Carry the relevant identity and resource context across services, and enforce the applicable permission at processing and delivery.
| Access condition | Before | After |
|---|---|---|
| Access remains valid | Export delivered | Export delivered |
| Access revoked before delivery | Export delivered | Delivery denied |
| Different workspace | No record data | No record data |
These fictional results show how a report can connect a business workflow, a service boundary, and a specific remediation decision.
02 / CUSTOM TOOLINGCan an AI integration stay inside its permissions?Engineer a control around identity, permitted actions, and the systems a tool can reach.View exampleClose example
Fictional AI integrationPermission enforcementIllustrative control design
Example control / AI integrationIllustrative
Make permission a condition of execution.
- Input
- Trusted user and workspace identity, the requested operation and resource, and the integration’s permitted scope.
- Control
- Evaluate permission before dispatch. A model’s request does not supply its own authority; missing identity or policy prevents execution.
- Integration
- Place the check at the tool boundary and connect it to the team’s existing identity, policy, and review systems.
- Output
- An enforced allow or deny decision, with a reason and policy version for review. Record enough context to investigate without copying sensitive payloads.
| Requested action | Expected behavior |
|---|---|
| Permitted action with complete context | Allowed; decision recorded |
| Action outside the user’s allowed scope | Denied before execution |
| Required identity or policy missing | Execution withheld; reason returned |
This is an illustrative engineering design. The control, integrations, and validation plan are shaped around the client’s environment.
03 / ALLMINDDid remediation remove the exposure?Follow a finding through investigation, patch planning, and verification.View exampleClose example
Fictional patch cycleClient-directed timingIllustrative Allmind workflow
Example workflow / Testing & patchingIllustrative
Investigate. Plan. Remediate. Verify.
- 01Investigate the exposure
Connect the observed behavior to the relevant service, configuration, and installed state. Record the impact and the conditions involved.
- 02Plan the change
Identify the appropriate update, dependencies, and rollback approach. Your team sets the priority, scope, and change window.
- 03Carry out remediation
Apply the agreed update through the chosen deployment workflow, recording what changed and any incomplete steps.
- 04Verify the result
Check the deployed state, revisit the original behavior, and confirm that intended operation still works.
- Sample result
- The planned update is present, the assessed behavior is no longer reproduced, and the intended-use checks pass.
- Open question
- Other deployments of the service have not yet been assessed in this example.
- Next decision
- Close the finding for the verified deployment and schedule the remaining systems for assessment.
The results above are fictional. Allmind is available to clients; scope, integrations, and responsibilities are agreed for each engagement.
How we evaluate the evidenceObserve · Compare · Conclude
01 / Observe
Record the conditions.
Describe what happened, the environment, and the permissions or preconditions the result depends on.
02 / Compare
Check other explanations.
Use meaningful controls and repeat observations where appropriate. Explain what each comparison supports.
03 / Conclude
Keep the claim bounded.
Separate demonstrated impact from hypotheses. State what remains uncertain and what a fix needs to change.
For AI systems, look at the consequence. A changed answer alone does not establish a security failure. The report should explain the observed effect, the boundary involved, and the limits of the evidence.
Who is behind Arquebus
Technical depth.
Clear leadership.
Founded by Aidan Vasconi, Arquebus brings together independent research, enterprise security engineering, and experience leading teams, products, and engagements.
Our focus includes authorization, APIs, and the boundaries where AI agents meet tools and data. We communicate the evidence, its limits, and the practical choices in front of the team.
Research is conducted within authorized scope. Confidential findings stay with the affected organization and its disclosure process.
Let's talk
Bring us the question
you need answered.
Tell us what you are building, reviewing, or trying to protect. We will find the right starting point: an assessment, a tool built for your environment, or the Allmind program.
[email protected]Reporting a security issue affecting Arquebus? [email protected]