Inferaq Trust Centre
Security at Inferaq
How Inferaq approaches secure engineering, AI security, access control, suppliers, monitoring and incident management.
Last updated: 19 September 2026
Inferaq treats security as part of design and delivery—not a final checklist. Controls are selected according to the service, information, threat model and contractual requirements. This public page describes principles; it does not disclose configurations that could weaken security.
1. Governance and responsibility
Security responsibilities are assigned throughout discovery, architecture, development, deployment and support. Material risks are documented, owners are identified and decisions are reviewed in proportion to impact. Client-specific responsibilities are recorded in the relevant contract, architecture and operating model.
2. Secure engineering
- threat modelling and abuse-case review for material systems;
- least privilege, separation of duties and controlled administrative access;
- server-side secret management and no production secrets in public code;
- peer review, dependency and secret scanning, and proportionate application testing;
- secure defaults, input validation, output encoding and defence-in-depth headers;
- encrypted transport and encryption at rest where appropriate;
- logging designed to support detection without collecting unnecessary content; and
- documented release, rollback, backup and recovery arrangements for supported services.
3. AI and agent security
AI systems introduce risks such as prompt injection, data leakage, unsafe output, excessive agency, insecure tool use, poisoned knowledge and unbounded consumption. Inferaq designs bounded permissions, approved knowledge sources, human approval gates, structured output controls, rate and token limits, evaluation, monitoring and incident paths according to the use case.
Public IQ has no access to unpublished doctoral research, private client data, administrative systems, payments or general-purpose privileged tools. A successful prompt injection should not create access that the underlying system does not possess.
4. People, suppliers and data
Access is granted according to role and removed when no longer needed. Confidentiality, security awareness and appropriate contractual obligations apply to personnel and suppliers. Supplier risk is considered before sensitive data or critical operations are entrusted to a service.
5. Monitoring and incident response
Inferaq aims to identify, contain, investigate, recover from and learn from security incidents. Where an incident creates a legal or contractual notification duty, affected parties and regulators will be informed within the applicable timeframe. Evidence is preserved proportionately and remediation is prioritised according to risk.
6. Shared responsibility
Clients remain responsible for accurate requirements, authorised users, endpoint and identity security, lawful data, timely decisions and controls assigned to them. Inferaq remains responsible for the controls it has expressly accepted. Security cannot be guaranteed absolutely, and no public statement replaces a service-specific assurance review.
7. Reporting a concern
Potential vulnerabilities should be reported under the Responsible Disclosure Policy. For an urgent concern, email info@inferaq.com with “CONFIDENTIAL SECURITY REPORT” in the subject. Do not include secrets in an initial unencrypted message.
Last updated: 19 September 2026