Our principles
- Assume the agent is tricked. We don’t rely on the model resisting prompt injection: we design so that even if it follows one, it has no credentials to hand over and no direct way out.
- If it can’t be inspected, it doesn’t leave. If the gateway can’t inspect something, it blocks it.
- No one approves their own request. Whoever asks for an exception never approves it, including within our team.
- Evidence, not promises. Our barriers are verified with repeatable tests that can run in front of the customer.
Data custody
| Data | Where it lives | Who decides retention |
|---|---|---|
| Code and the agent’s work | In the workspace and your repository | Your company |
| Credentials | In a vault; only the gateway uses them | Your company |
| What is sent to the AI model | At the model provider, in your account and region where possible | Your company and its provider contract |
| Log and evidence | Separated: the event chain and its content are stored apart | Your company |
How we build
We build Harkaq following NIST’s Secure Software Development Framework (SSDF) and OWASP’s Application Security Verification Standard (ASVS, level 2). The images and packages we publish are signed and come with a software bill of materials (SBOM). No infrastructure is created by hand: everything is defined as code and reviewed.
Vulnerability disclosure
If you find a vulnerability in Harkaq or on this site, email security@harkaq.com. We commit to:
- Acknowledge receipt within 3 business days.
- Keep you informed while we fix it.
- Take no legal action against good-faith research that doesn’t access third-party data or disrupt the service.
Our security contact is also published at /.well-known/security.txt.