1. Why this matters
SemantiqWall decides whether an AI agent's action is allowed only when the agent asks. The protection is as good as the integration: an action the customer's agent never sends to SemantiqWall is not checked. This document states who does what.
2. Responsibility matrix
| Area | SemantiqWall | Customer |
|---|---|---|
| Physical datacenter, hardware, network up to the server | Through its hosting provider (policy 09) | - |
| Server, OS, database, patching, backups, encryption in transit | Yes (policies 02, 03, 06, 07) | - |
| Application security of the platform and SDKs | Yes; vulnerabilities handled under the public disclosure program | Keep SDKs updated to the latest version |
| Tenant isolation | Yes - enforced in code and tested | - |
| Platform authentication | MFA is mandatory and cannot be disabled; rate limits; step-up MFA for critical approvals | Add only the right people as members, give each the lowest role, protect their authenticator devices and recovery codes |
| Users and roles | Provides roles (owner, admin, approver, analyst, viewer) and separates approving from configuring | Decide who holds each role; review members at least quarterly; ask for removal of people who leave |
| API keys | Generates strong keys, stores only hashes, scopes each key to one environment, rate-limits, audits creation and revocation | Keep keys in a secret manager, never in code or in agents' prompts; use separate keys for each environment (a key only works in the environment it was issued for); revoke on exposure or staff change; rotate at least yearly |
| Agent integration | Provides SDKs and API that fail closed when SemantiqWall is unreachable (except low-impact actions the customer explicitly allowed during an outage) | Route every sensitive tool call through the SDK before executing it; do not execute when the answer is deny or when approval is pending |
| Inventory | Discovery aids (repository analysis, inventory import) | Declare all agents, tools and credentials and keep the inventory current |
| Policies | Deterministic engine, simulator, observation mode, assisted activation with automatic revert | Choose, test and activate policies; decide what requires approval; review blocked and approved actions |
| Approvals | Approval flow with expiry, MFA and audit | Approvers check each request before approving; respond before it expires |
| Data sent to the API | Masks parameters, stores the minimum, protects stored data | Send only what the decision needs; use pseudonymous IDs for people; do not send sensitive personal data, full documents or secrets |
| Audit trail | Append-only, hash-chained, verifiable in the panel | Review it; export it (it is part of the organization export) for your own retention needs |
| AI-assisted features (optional) | Send only the minimum to the AI provider; AI proposes, never decides; proposals need human review | Review AI suggestions and pull requests before using or merging them |
| GitHub App (optional) | Requests only needed permissions; opens pull requests, never merges | Install only on the repositories needed; review every pull request |
| Incidents | Detect and notify affected customers (policy 05) | Report suspected misuse of their account; notify their own users and regulators when they are the controller |
| Legal role for agent data | Processor, acting on the customer's instructions | Controller: legal basis, notices to their own users, data subject requests |
| Data at the end of the contract | Full JSON organization export for owners and administrators, available for 30 days after termination, then deletion (policy 08) | Export what they need before the deadline |
3. Vendor verification program
- SemantiqWall checks what can be seen publicly (level 1) and reviews the vendor's answers and evidence against the published criteria (level 2 and 3). It is a review of evidence, not a certification or an audit.
- The vendor is responsible for the truth of its answers and evidence and for telling SemantiqWall when something changes. Verification expires and is re-reviewed.
- Customers who use the public lookup remain responsible for their own supplier decisions.
4. Configuration guidance for customers
- Create one environment per stage (for example production and test) with separate API keys.
- Start policies in observation mode, review decisions, then activate.
- Require approval for critical actions (exports, deletions, payments, permission changes).
- Keep at least two owners so that one person leaving does not lock the organization.
- Check the audit-chain status in the panel regularly.
5. Interoperability and portability
- The API uses HTTPS and JSON; official SDKs exist for PHP and TypeScript and are today the reference for the API. Commitment: a published API reference (owner: Founder, target 2027-03-31).
- The agent inventory can be imported from a documented JSON format.
- In place: a full organization export in JSON (members, environments, API key metadata, inventory, policies, decisions, approvals, cases, protection plans, repository analyses, vendor profile and the audit log with its hashes), available to owners and administrators from the Organization page. Secrets are never included. The export is its own JSON format; it is not the inventory import format.
- Data formats are open (JSON, CSV where offered); no proprietary tool is needed to read an export.
- API changes that break existing integrations will be announced before release, with a transition period.
6. Review
This model is reviewed at least once a year and when a feature changes who does what. Customers are told about material changes before they take effect.