Security, compliance and sovereignty

The whole platform runs in our data centres in Türkiye; primary and secondary systems are in-country. Code context, logs and backups never leave Türkiye. This is aligned with the in-country requirement of banking IT regulation.

The systems run in data centres located in Türkiye that hold international Tier and national TS EN 50600 certifications and are aligned with financial-sector regulation (banking and payments regulators). The data centre’s name, documents and certificates are shared in the discovery session and in writing in the contract annex.

The default is a logically isolated workspace for the organisation on sovereign shared infrastructure. At the organisation’s choice a dedicated tenant, a dedicated GPU pool or an on-prem deployment in the organisation’s own data centre is possible; the architecture is the same in all three.

No cloud provider is used for model serving. Data-centre services come from providers located in Türkiye and approved by the regulators; the provider is named in the contract and the organisation is informed in advance of any change.

There are two options. In the VPN model a site-to-site IPsec tunnel is established between the organisation’s gateway and Aginies, only HTTPS (443) is used inside the tunnel and the Hub accepts traffic only from the IP addresses allocated to the organisation. In the internet model the endpoints are reachable over TLS 1.3 from the public internet; the organisation opens a single outbound rule (Aginies public IP, TCP 443) and its egress IPs are added to an allowlist. The allowlist keeps rate-limit and auto-block rules from cutting the organisation’s traffic; access itself is granted by identity. In both models the IP addresses and parameters are given in the technical annex.

No. The Hub is reachable only through the tunnel interface; it has no public endpoint, so there is no DDoS or scanning surface.

TLS 1.3 in transit inside the VPN tunnel (end-to-end, independent of the tunnel); AES-256 at rest. Key management is on the Aginies side; bring-your-own-key is available in the dedicated deployment.

The extension honours corporate proxy settings. TLS inspection with the organisation’s own certificate is technically possible; whether the inspection device sees code context is then the organisation’s own policy. Our recommendation is to keep end-to-end TLS inside the tunnel.

Identity lives in the organisation’s identity provider: SSO via SAML or OIDC, MFA by the organisation’s policy. The licence key is organisation-level and grants no access on its own; every request carries a short-lived per-user token. When a user is disabled at the organisation, Aginies access drops at the same moment.

Authorisation is group-based: which team reaches which model, with which quota and which features (completion, chat, agents); the organisation’s administrator manages it from the Platform Aginies dashboard. Seats and quotas are set by contract.

Production access is role-based, named and logged; access to prompt and response content is opened only on the organisation’s written request for support purposes, and the record is shared with the organisation. Under the default retention policy, content is not kept at all.

Yes. Administrative actions are written to the same audit trail: who changed what, and when. Policy changes are versioned.

Only the context the request needs: the relevant part of the open file, cursor surroundings, selected symbol definitions and the developer’s prompt. The repository as a whole, build outputs and environment files are never sent. The context limit and the exclusion list (.env, certificates, key files) are configured with the organisation and visible in the extension.

The masking layer in the Hub scans the prompt for keys, passwords, connection strings and personal-data patterns; matches are masked before they reach the model. The rule set can be extended with the organisation’s own patterns; masking events appear in the trace.

Metadata (user, time, model version, duration, tokens, cost) is always recorded. Retaining prompt and response content is the organisation’s decision: off (default), or encrypted retention for a period the organisation sets. Deletion at expiry is automatic and evidenced.

No. The organisation’s prompts and responses never enter any model’s training or fine-tuning data; this is an explicit clause in the contract. If organisation-specific fine-tuning is requested, a separate model version owned by the organisation is produced only from data the organisation approves.

Backups are kept inside Türkiye, encrypted and under a separate access policy; if content retention is off, backups contain no content either. Backup retention and disaster-recovery targets are written in the contract annex.

The organisation’s workspace, configuration and traces are exported in the requested format; all data is then deleted within the agreed period and deletion evidence is provided. An organisation-specific model version is handed over on request, otherwise destroyed.

Coding models from the Hub Aginies catalogue served on in-country GPUs: open-source-based on-prem models (aginies-talay-2, aginies-sunkar-1) and fine-tuned enterprise versions. No prompt goes to an outside provider; the cloud model proxy is off in the organisation’s workspace and can be locked at policy level.

Models enter the catalogue after Aginies reviews them and validates them with a test corpus; every model is versioned. A model change in the organisation’s workspace happens with the organisation’s approval and prior notice; the previous version is kept for rollback for an agreed period.

Model output is a suggestion; the developer reviews the code and it passes the organisation’s existing CI, code review and static analysis. On the Aginies side, check families for prompt injection and off-policy output run in the test corpus; organisation-specific forbidden patterns can be added as policy.

The generated code belongs to the organisation. The licences and commercial-use terms of the open-source models in use are listed in the contract annex.

The extension is signed and distributed as an approved version through the organisation’s enterprise IDE Registry; no public marketplace is needed. Versions can be pinned; updates are released with the organisation’s approval.

The extension connects only to the Hub address the organisation configures; there is no other endpoint. Error-report telemetry is minimal, carries no content and can be switched off.

Without a connection the extension goes quiet; it keeps no local queue or cache, so no code context accumulates on the device. It resumes when the connection returns.

The extension’s software bill of materials (SBOM) and dependency scan are shared on request; a source-code review can be arranged under an NDA.

The platform is compliant with the SOC 2 Type II and ISO 27001 control sets; the control-set document is shared for internal audit. The KVKK data-processor agreement and privacy notices are ready.

If the organisation is a bank, the service may fall under its outsourced-support classification; the required contract clauses (audit right, sub-processor notification, exit plan, information-security obligations, audit access for the regulator and the organisation) are then added. The in-country requirement is already met by the architecture.

Independent penetration tests are performed regularly; the executive summary is shared and finding-closure evidence is provided. The organisation may run its own test; scope and timing are agreed in advance.

For an incident affecting the organisation, first notification is made within 24 hours, followed by a root-cause and corrective-action report. KVKK notification duties are coordinated with the organisation as data controller.

Availability and latency targets are written in the contract; capacity is reserved by the organisation’s seat count and the GPU pool scales in-country. Maintenance windows are announced in advance.

Yes. The kill-switch is in the organisation administrator’s hands: it cuts access instantly per user, team or organisation; the organisation can also close the VPN tunnel on its own side to end all access.

Every change to the Hub, the extension or the models that affects the organisation is announced in advance with release notes; critical changes can be tied to the organisation’s approval. Policy and configuration changes are versioned in the audit trail.