Question 1

Where do the systems run? Does data leave Türkiye?

Accepted Answer

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.

Question 2

Which data centre, and to which standards?

Accepted Answer

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.

Question 3

A dedicated environment or a shared one?

Accepted Answer

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.

Question 4

Who are the sub-processors? Do you use a cloud provider?

Accepted Answer

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.

Question 5

How is the connection set up? Which ports and addresses?

Accepted Answer

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.

Question 6

Is Hub Aginies exposed to the internet?

Accepted Answer

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

Question 7

How is encryption handled?

Accepted Answer

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.

Question 8

Can the organisation’s proxy or SSL inspection sit in between?

Accepted Answer

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.

Question 9

How are users authenticated? What if the licence key is shared?

Accepted Answer

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.

Question 10

Who can use which model, and how much?

Accepted Answer

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.

Question 11

Can Aginies staff access the organisation’s data?

Accepted Answer

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.

Question 12

Do administrative actions leave a trace?

Accepted Answer

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

Question 13

What exactly does the extension send?

Accepted Answer

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.

Question 14

Do secrets (passwords, API keys) reach the model?

Accepted Answer

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.

Question 15

Are prompts and responses retained? For how long?

Accepted Answer

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.

Question 16

Is our data used to train models?

Accepted Answer

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.

Question 17

Where are backups, and who can access them?

Accepted Answer

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.

Question 18

What happens when the contract ends?

Accepted Answer

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.

Question 19

Which models are used? Does anything go to an outside provider?

Accepted Answer

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.

Question 20

Who selects the models, and how are they updated?

Accepted Answer

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.

Question 21

Is model output safe? Can it produce harmful code?

Accepted Answer

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.

Question 22

Licensing and IP: who owns the generated code?

Accepted Answer

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.

Question 23

Where is the extension installed from, and is it signed?

Accepted Answer

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.

Question 24

Does the extension connect anywhere else? Is there telemetry?

Accepted Answer

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.

Question 25

What if the connection drops? Does it work offline?

Accepted Answer

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.

Question 26

Can we review the source code or an SBOM?

Accepted Answer

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.

Question 27

Which certifications do you hold?

Accepted Answer

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.

Question 28

For banks: is this an outsourced support service under banking regulation? Is there an audit right?

Accepted Answer

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.

Question 29

Are penetration tests performed? Can we see the results?

Accepted Answer

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.

Question 30

What is the notification time for a security incident?

Accepted Answer

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.

Question 31

Service level and capacity?

Accepted Answer

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.

Question 32

Can we cut the service instantly in an emergency?

Accepted Answer

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.

Question 33

How does change management work?

Accepted Answer

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.

Flow	Source	Target	Port / protocol	Access and control
1	Developer IDE · Code Aginies extension · organisation egress IPs	code-api.aginies.com → Aginies public IP	TCP 443 · HTTPS, TLS 1.3	Internet; organisation IPs exempt from rate limit and auto-block. SSO token, seats and quota, masking, per-request trace.
2	Aginies application server (internal interface)	GPU model server (internal network)	Internal network · model API	Internal network only; accepted only from the application server, never leaves the data centre.
3	GPU model server	Internet	—	None: the server has no public IP and no internet egress; prompt and response are not stored or used for training.
4	Aginies operations team	Aginies application server · administration	TCP 22 · SSH	Aginies operations VPN only; closed to the internet and to the organisation. No SSH or VPN needed on the organisation side.
5	Aginies application server	External model providers	—	None: coding models run only on in-country GPUs; code context never leaves Türkiye.
6	Organisation applications (optional, direct model access)	hub-api.aginies.com → Aginies public IP	TCP 443 · HTTPS, TLS 1.3	Same allowlist, identity and quota; API access to the models in the Hub catalogue.

SOC 2 Type II	Compliant platform; the control set is documented for internal audit
ISO 27001	Compliant information security management
GDPR & KVKK	Personal data map, data residency guarantee, deletion and access requests
Banking IT regulation	For banks, primary and secondary systems in-country; audit-ready deployment
SSO / SAML & RBAC	Fine-grained roles, workspace isolation, per-workflow access policies
PII masking	Sensitive data masking at ingestion, configurable redaction
Audit trail	Input, output, model version, rule set and user for every agent action and model call
Kill-switch	Emergency shutdown and automation limits on critical decisions; mandatory human approval

Sector	Frame	Recommended deployment
Banking →	Banking IT and electronic banking regulation: primary and secondary systems in Türkiye, audit right in the outsourcing contract, cloud model subject to bank-specific permission	Start with the sovereign shared deployment in our data centres in Türkiye (isolated bank workspace, VPN or allowlist access); on-prem in the bank’s data centre for scenarios classed as primary systems.
Fintech & Payments →	Central-bank payment and e-money IT communiqué: community cloud only with an approved provider; primary systems in-country	In the community cloud of a provider on the central bank’s approved list, or in the institution’s own data centre; GPU capacity in-country, models from the Hub catalogue.
Insurance →	Insurance regulator rules and insurance IT requirements: claim and policy decisions reasoned, time-stamped, open to audit	Dedicated region in Türkiye or the sovereign shared deployment; vision models for damage photos and health data on in-country GPUs.
Retail & E-commerce →	Consumer law and distance-selling rules: withdrawal, return and delivery deadlines coded into agent rules	Sovereign shared deployment; GPU capacity scales on usage at seasonal peaks, customer data stays in Türkiye.
Telecom →	Telecom regulator rules and the electronic communications law: subscription, contract and number-porting operations recorded and traceable	Sovereign shared deployment or a dedicated tenant in the operator’s own data centre; speech models on in-country GPUs, connected to the existing switch over SIP.
Healthcare →	Personal health-data regulation and special-category data: health data inside the hospital perimeter, access by role and purpose, every access logged	On-prem in the hospital data centre; models inside, no external connection. For hospital groups, a dedicated tenant in the group data centre.
Manufacturing & Automotive →	OT security (IEC 62443 approach): agents connect to the production network read-only and issue no commands; OT/IT separation kept	Hybrid: read-only agents and historian access near the production network on site, decision and document agents in our data centre in Türkiye or the organisation’s own.
Logistics →	Customs law: declaration and document preparation by the agent, declaration and signature with the authorised broker	Sovereign shared deployment; TMS, telematics and carrier APIs connected through an allowlist, shipment data stays in Türkiye.
Energy & Utilities →	Energy regulator consumer-service and connection regulations: dispute, correction and application deadlines coded into agent rules	Sovereign shared deployment for customer operations; grid-adjacent read-only agents on-prem in the company data centre with critical-infrastructure separation kept.
Government & Public Sector →	Presidential information and communication security guide: deployment in the institution’s data centre, air-gap included; open-weight models inside	On-prem in the institution’s own data centre; air-gapped where required. For municipalities and affiliated bodies, a dedicated tenant in the public cloud.
Defence & Aerospace →	Defence-industry agency and export-control law: control-list mapping by the agent, licence and sharing decisions with the authorised compliance officer	Air-gapped deployment: models, platform and data inside the closed network; updates as approved packages, remote maintenance only in windows the organisation opens.
IoT & Connected Devices →	Personal-data law and device data: telemetry inside the organisation, user data purpose-limited	Hybrid: device cloud and time-series data on the existing infrastructure, agents and small models in our data centre in Türkiye or the manufacturer’s own.
Software Delivery →	Source code and intellectual property: code never leaves the organisation; Code Aginies and completion models on-prem	Code Aginies and coding models in the organisation’s data centre or in our data centre in Türkiye through the closed-circuit deployment; SDLC agents connected to Jira, Git and CI/CD with service accounts.

Your data stays where it must.

The code-assistant scenario: from IDE to model

The seven steps of one completion request

Two access models: VPN tunnel or allowlist over the internet

Goes from the organisation to Aginies

Goes nowhere

The first questions a security team asks

Same architecture, three deployments

Deployment options

On-premise / air-gap

Hybrid

Private cloud / dedicated region

GPU-as-a-Service

Compliance matrix

Model-agnostic, fine-tuned

Which frame each sector answers to, and with which deployment.

Time to move from experimenting with AI to transforming with it.