LLMs, confidentiality, and cost

The model should be a choice of the project, not part of its architecture.

Gabion contains no mandatory LLM of its own and does not tie the production pipeline to a single AI provider.

The team chooses a model on the basis of the complexity of the task, the requirements on the data, the hardware available, and the cost. The architectural rules, the modules, and the deterministic checks stay in Gabion and do not disappear when the model changes.

The LLM interprets the intent, analyzes the context, builds a plan, and writes code. Gabion provides it with tools, the structure of the project, coherent components, and the results of the checks.

A change of LLM must not mean a change to the architecture of the product.

The specific integrations depend on the version of Gabion and on the AI assistant in use. The following modes are architecturally possible.

The existence of an architectural mode does not mean that every model and every gateway has already been tested. A public compatibility list has to contain only connections that have actually been verified.

An LLM cannot carry out a substantive task without context. But connecting a model to an AI client or to MCP must not by itself mean permission to read the whole repository, production data, or secrets.

The permitted models, the available tools, and the categories of data are determined separately for each project.

Who assembles the context

The context can be assembled by several participants:

• a human selects files or writes a description;
• the AI client reads the permitted area;
• Gabion provides the structure, the contracts, and the diagnostics;
• an MCP tool returns the result of a permitted operation;
• the model requests additional information;
• an external gateway changes or logs the request.

Before a specific guarantee is published, the role of every component has to be documented precisely.

Gabion must not claim full control over the context when part of the files is selected by an external AI client.

The minimum necessary context

For each operation it is useful to apply the sequence:

1. define the task;

2. identify the scenarios affected;

3. select the minimum area of the project;

4. provide the contracts and the structure;

5. add the specific files;

6. request additional context only where it is needed;

7. exclude secrets and user data;

8. record which provider receives the material.

Minimization reduces:

• the risk of unnecessary disclosure;
• the cost of inference;
• the noise;
• the chance of a false connection between files;
• the volume of the logs;
• the processing time.

It does not guarantee that the result from the model is correct.

The context of a module

The AI can receive the information it needs in order to work with a module:

• the permitted contract;
• the manifest;
• the files that belong to the project;
• the extension points;
• the diagnostics;
• the tests.

The AI client used by the client must not automatically receive:

• the whole internal Pikiner module catalog;
• the source templates of other modules;
• the modules of other projects;
• the credentials of the storage;
• the internal operations of the module-management CLI.

The unique logic of the client

Unique business logic stays in the client project.

It can be sent to the chosen LLM only in a mode permitted for that project.

Pikiner must not use such logic:

• in another client project;
• in a public Showcase;
• in general documentation;
• in training a general model without a separate, explicit agreement;
• in an anonymized module without actually removing the unique rules.

Anonymizing the names is not sufficient if the business rule itself makes it possible to identify the client or the product.

The context for a shared Pikiner module

If a repeatable technical mechanism becomes a shared module, the following must not be carried into the working area of that module:

• the code of the client's old product;
• unique business logic;
• production data;
• the test data of the client;
• secrets;
• names;
• internal identifiers;
• confidential documents;
• prompts with sensitive context;
• model responses that contain client material.

Only a self-contained, anonymized technical component enters a shared module.

Production data

The following are preferable for development:

• synthetic data;
• anonymized data sets;
• minimal samples;
• a test environment;
• test accounts.

If production data is necessary, the following are determined before access:

• the purpose;
• the composition;
• the volume;
• the place of processing;
• the permitted model;
• the recipients;
• the retention period;
• the deletion;
• the logging;
• whether a DPA is required.

Production data must not reach prompts automatically while an application error is being diagnosed.

Tools are stronger than context in text

The model can receive data not only in a prompt, but through a tool call.

For every MCP tool it is therefore necessary to determine:

• the area of the project;
• the permitted paths;
• the type of data returned;
• the maximum volume;
• the filtering of secrets;
• whether human approval is required;
• the logging;
• whether the result can be sent externally.

A prohibition on writing a secret into a prompt is useless if a tool returns the file containing that secret without restriction.

What a human has to see before material is sent

For a sensitive operation the interface has to display:

• which model is to be used;
• which provider;
• which data will be sent;
• from which project;
• for what purpose;
• what action the tool will perform;
• the possible consequences;
• whether the context can be reduced.

The specific list of confirmations depends on the actual implementation of Gabion and of the AI client.

A local model

If a local model is used, the context need not be sent to an external LLM provider.

But the following have to be checked separately:

• the AI client;
• MCP;
• embeddings;
• reranking;
• telemetry;
• crash reporting;
• package managers;
• model downloads;
• the update service;
• the external APIs of the project.

The phrase "a local model" describes where inference happens, not the whole network perimeter of development.

A verifiable boundary

Before a particular mode is promised, a test has to be run that shows:

• which files were read;
• which MCP tools were called;
• which data formed the prompt;
• which endpoint received the request;
• which local logs were created;
• which network connections were made;
• which data remained after the task finished.

Without such a check, the statement that "the model sees only what it needs" remains an architectural goal rather than a confirmed property.

The model receives not what technically exists on the machine, but only what is permitted and was actually sent to it by a specific process.

Data does not move directly from the project into an abstract "AI".

The real process can involve the project, the AI client, Gabion, MCP, a corporate gateway, the model provider, local logs, and external tools.

Each part has its own area of control, its own settings, and its own retention rules.

1. 1. The client project

   The project can hold:

   • the source code;
   • the business logic;
   • the tests;
   • the configuration;
   • the migrations;
   • the technical documentation;
   • synthetic data;
   • local development data;
   • links to external resources.

   Production secrets and live credentials must not be held in the source code or in the Git history.

   The owner of the project determines:

   • who has access;
   • which directories are permitted to the AI;
   • which material counts as confidential;
   • which data must not be sent to a model;
   • which participants may change the policy.

2. 2. The AI client or agent environment

   The AI client can:

   • read files;
   • assemble prompts;
   • combine context;
   • call MCP;
   • run commands;
   • keep a history;
   • create logs of its own;
   • send a request to the model provider.

   Gabion does not automatically control the storage and transmission functions of an external AI client.

   Before it is used, the following have to be checked:

   • which files it reads;
   • how it selects context;
   • where it keeps its history;
   • which endpoints it uses;
   • which tools are available;
   • whether telemetry can be disabled;
   • whether data can be deleted;
   • which human confirmations it uses.

3. 3. Gabion Runtime

   Gabion can provide:

   • the structure of the permitted project;
   • the architectural contracts;
   • the manifest;
   • MCP tools and resources;
   • the checks;
   • the diagnostics;
   • the human interface;
   • control over the permitted operations.

   The Runtime answers only for the data and the actions that actually pass through it.

   It must not claim control over:

   • files read directly by an external AI client;
   • the history of an external IDE;
   • the account with the LLM provider;
   • an external gateway;
   • the logs of a cloud provider;
   • third-party tools not called through Gabion.

4. 4. The MCP connection

   MCP connects the AI client to the permitted tools and resources.

   For every element it is necessary to document:

   • the name;
   • the purpose;
   • the input parameters;
   • the data returned;
   • the area of the project;
   • the maximum volume;
   • whether it can change files;
   • whether confirmation is required;
   • the logging;
   • the handling of errors;
   • the filtering of sensitive data.

   Compatibility with MCP does not mean that any MCP client is automatically supported or applies the same security policy.

5. 5. A corporate AI gateway

   A company can route requests through a gateway of its own.

   A gateway can govern:

   • the permitted models;
   • the API keys;
   • the routing;
   • the logging;
   • redaction;
   • rate limits;
   • budget limits;
   • the regions;
   • the resilience;
   • the audit.

   Pikiner must not promise the properties of a specific gateway without verifying the integration and the terms of its owner.

   A gateway can reduce uncontrolled use of models, but it also creates an additional place where data is processed and held.

6. 6. The cloud model provider

   The provider determines:

   • the processing of the request;
   • the storage;
   • the use of data for improvement or training;
   • the geography;
   • the access of personnel;
   • subprocessors;
   • abuse monitoring;
   • the logs;
   • the deletion;
   • the contractual guarantees of the specific plan.

   Gabion cannot change those rules technically once the request has been sent to the provider.

   The organization has to check the current terms of the exact product and plan in use, rather than the provider's general marketing page.

7. 7. A local model

   With local inference, the processing by the model stays in a controlled environment.

   The owner of the environment is responsible for:

   • the installation;
   • the model files;
   • user access;
   • the updates;
   • the compute;
   • the logs;
   • the network connections;
   • the security of the model runtime;
   • the deletion;
   • the backups.

   A local model does not remove the possible external connections of the AI client, Gabion, a package manager, or other tools.

8. 8. The external tools of the project

   The following may be used during a task:

   • Git hosting;
   • an issue tracker;
   • documentation;
   • a package registry;
   • a cloud console;
   • database tools;
   • CI/CD;
   • observability;
   • external APIs.

   Every tool creates a separate data boundary.

   Permission for the AI to work with code does not automatically mean permission to work with the production database, the cloud account, or the incident system.

9. 9. The local Gabion logs

   Before publication it is necessary to determine whether Gabion retains:

   • tool calls;
   • the results of checks;
   • file paths;
   • fragments;
   • prompts;
   • model responses;
   • project identifiers;
   • information about the token;
   • errors;
   • usage metrics.

   For each type of data it is necessary to state:

   • where it is held;
   • the format;
   • the period;
   • the access rights;
   • the encryption, where it is applied;
   • the clearing;
   • the export;
   • the deletion.

   If specific data is not retained, that has to be confirmed by a test of the current version.

10. 10. Telemetry

    Telemetry can cover technical events of the product, but it must not covertly collect code or business data.

    Before it is enabled it is necessary to document:

    • the composition of the events;
    • the default mode;
    • the endpoint;
    • the identifiers;
    • the retention period;
    • the processors;
    • whether it can be disabled;
    • the effect of disabling it;
    • the behavior in local mode.

    The claim that "telemetry is disabled" has to be verified by a network test, not merely by the absence of a checkbox.

11. 11. Crash reports

    An error report can accidentally contain:

    • a file path;
    • the name of the project;
    • a fragment of code;
    • a configuration value;
    • a secret;
    • a prompt;
    • a model response;
    • user data.

    A verified redaction mechanism has to be applied before it is sent.

    A sensitive project may require:

    • a preview;
    • explicit confirmation;
    • complete disabling;
    • local retention without sending.

12. 12. The license check

    Verifying the token is a separate network process and must not automatically send:

    • source code;
    • prompts;
    • model responses;
    • user data;
    • business logic;
    • secrets.

    The following have to be documented:

    • the endpoint;
    • the identifiers;
    • the result;
    • the logs;
    • the retention period;
    • the offline behavior;
    • subprocessors.

    The production application takes no part in the Gabion license check.

The responsibility map

The contractual boundary

Before work begins on a confidential project it is necessary to determine:

• the roles of the parties;
• the applicable Privacy Policy;
• whether a DPA is required;
• the list of subprocessors;
• the permitted providers;
• the region of processing;
• the retention period;
• the incident process;
• the procedure for deletion;
• the restrictions on training;
• the rules on access by personnel.

A technical diagram does not replace the legal determination of the controller, processor, or service provider roles.

Those roles are established by the actual processing and by the applicable law.

Data sent in error

A project needs a response process:

1. stop any further transmission;

2. identify the data;

3. identify the provider and the endpoint;

4. check the logs;

5. revoke the compromised secrets;

6. request deletion, where it is available;

7. assess the contractual and legal obligations;

8. notify the participants required;

9. remove the cause;

10. verify the new process.

Deleting a message from the interface of the AI client does not always mean the data has been deleted at the provider.

Gabion answers for its own tools and data. The full boundary is determined by the whole chain from the project to the model.

A fully local scenario has to be assessed as a whole: the model, the embeddings, reranking, telemetry, updates, external package repositories, and other network dependencies. A local LLM does not by itself prove the absence of outbound traffic from the whole process.

Quantization reduces the demands on memory and compute, which makes it possible to run a model locally or to serve repeatable tasks more cheaply. At the same time, planning, adherence to complex instructions, and the ability to correct unusual errors may all get worse.

Gabion is useful in that scenario not because it removes the difference between models, but because it takes part of the choice away from them and returns concrete, verifiable feedback.

The working model of the process

1. the LLM creates a change;

2. Gabion runs the applicable checks;

3. a violation is returned in structured form;

4. the model makes another attempt;

5. a human intervenes if the error repeats, if the task requires a decision, or if the limit set has been reached.

What has to be measured

• the proportion of tasks that succeed on the first attempt;
• the average number of iterations;
• the time to an accepted result;
• the number of human interventions;
• the cost of all the attempts, not of one request;
• the classes of error the checks do not detect;
• the difference between models on the real tasks of the project.

A cheap request is not a cheap task if reaching an accepted result takes many repetitions and correction by a human.

The price of a single request to a model does not show the real cost of AI-assisted development.

A cheaper model may require more attempts, more context, more corrections, and more human time. A more expensive model may not be worthwhile for a simple, repeatable task.

The correct unit of comparison is a change that has passed the checks and been accepted by the team.

What the costs are made of

An AI-assisted workflow can incur:

• the cost of input tokens;
• the cost of output tokens;
• model hosting;
• local compute;
• GPU;
• electricity;
• storage;
• embeddings;
• reranking;
• external APIs;
• a corporate gateway;
• observability;
• logs;
• test environments;
• CI;
• human time;
• repeated attempts;
• correcting mistaken changes;
• verifying the result;
• production rollback.

Gabion does not automatically control all of these costs.

Who pays for the external model

One of the following is determined for the project in advance:

• the model account belongs to the client;
• requests go through the client's corporate gateway;
• the client's local infrastructure is used;
• Pikiner pays third-party costs temporarily and invoices them in the way the SOW states;
• another expressly agreed arrangement applies.

Where possible, permanent production and AI accounts are held in the client's name.

This lets the client see usage, limits, invoices, and access for themselves.

What the Pikiner migration price includes

The migration price covers the agreed result of the project.

It does not automatically include:

• unlimited use of external LLMs;
• the client's cloud infrastructure;
• the client's GPU;
• paid APIs;
• model hosting;
• third-party licenses;
• provider fees;
• other external costs.

Applicable taxes and third-party costs are not included in the price unless the SOW expressly states otherwise.

What the client does not pay for separately

If delivering an already agreed SOW requires Pikiner to:

• create a new anonymized module;
• change an internal check;
• make an additional internal attempt;
• investigate its own production method;
• correct an error in its estimate;
• replace an internal approach to the implementation,

that is not billed to the client as a separate line.

The client pays for the agreed result, not for the development of Gabion or for the number of internal attempts Pikiner makes.

A local model is not free

Running locally removes or reduces the bill from the external LLM provider, but other costs arise:

• hardware;
• GPU memory;
• CPU;
• RAM;
• storage;
• electricity;
• cooling;
• installation;
• updates;
• monitoring;
• maintenance;
• setup time;
• reserving capacity.

The cost of slower work or of additional attempts also has to be taken into account, if the quality of the model is lower for the specific task.

The cost of an accepted change

For comparing models it is useful to measure:

• the number of requests;
• input tokens;
• output tokens;
• the duration;
• the number of tool calls;
• the number of failed checks;
• the number of corrections;
• human time;
• the cost of the test environment;
• the final status;
• whether the result was accepted;
• whether the result was released;
• whether a rollback was needed.

A simplified formula:

The cost of an accepted change = inference + infrastructure + checks + human time + rework.

This formula is not an accounting standard. It sets a practical unit of comparison.

Context and cost

The larger the context, the higher the following can be:

• the cost of the request;
• the latency;
• the volume of storage;
• the risk of disclosing unnecessary data;
• the number of irrelevant connections.

It is therefore useful to:

• select files by task;
• use contracts instead of the full source code of neighboring modules;
• avoid resending unchanged context without a reason;
• limit the logs;
• keep large data out of the prompt;
• send the diagnostics rather than all the output of a command.

Optimizing the context must not remove information needed for a correct solution.

Choosing a model by class of task

Different tasks can use different models.

For example:

• a simple transformation;
• a search;
• a multi-file change;
• designing a migration;
• diagnostics;
• documentation;
• a complex correction.

Automatic model routing must not be described as a Gabion feature if the choice is made by a human or by an external AI client.

For each class it is useful to determine:

• the permitted models;
• the maximum cost;
• the maximum number of attempts;
• the permitted data;
• the conditions for escalation;
• the mandatory checks.

Limiting the number of attempts

Repeating the same request can conceal a failing strategy.

After a set number of failed attempts, the task has to:

• stop;
• pass to a human;
• pass to a more suitable model;
• receive additional context;
• be divided;
• require the business rule to be clarified.

The threshold is determined by the policy of the project and must not be presented as a universal Gabion number.

Budget limit

If the provider or the gateway supports limits, a project can use:

• a monthly budget;
• a limit per user;
• a limit per model;
• a limit per task;
• a rate limit;
• a warning at a threshold;
• a block once the budget is exhausted;
• a manual increase.

Before a budget control feature is published, the following have to be checked:

• the source of the usage data;
• the delay in that data;
• the currency;
• the taxes;
• the rounding;
• cached requests;
• batch;
• retry;
• a change of provider price;
• the actions taken once the limit is reached.

Gabion must not promise an exact monetary limit if it receives only approximate data.

Notifications

Useful notifications can report:

• usage over a period;
• approaching a limit;
• unusual growth;
• a large number of retries;
• a task with a high cost;
• a model being unavailable;
• a switch of provider;
• a change of price.

A notification must not contain source code, a prompt, or user data.

Displaying an approximate cost

If the exact invoice amount is unavailable, the interface has to mark the value as an estimate.

The following are stated beside it:

• the source of the price;
• the date of the price;
• the categories included;
• the costs not accounted for;
• the currency;
• the possible delay in usage data.

An estimate from Gabion must not be conflated with the official invoice from the provider.

Protection against unexpected spend

The project policy has to determine:

• the permitted models;
• the owner of the account;
• the maximum spend;
• who may raise the limit;
• the behavior once the limit is reached;
• the permitted number of retries;
• the rules for background tasks;
• the restrictions on CI;
• disabling a compromised key.

Changing the model

Before changing the model it is necessary to compare:

• compatibility with the tools;
• quality on test tasks;
• the cost of an accepted change;
• the requirements on data;
• the region;
• retention;
• speed;
• availability;
• limits;
• behavior on error.

A low token price is not sufficient grounds on its own.

What Gabion can and cannot measure

Cost control begins with visibility. An exact limit is possible only where usage is genuinely measured and can be stopped.

An MCP tool can be more powerful than a text answer from the model. Permissions therefore have to depend on the project, the type of operation, and the risk.

Principles

• the minimum necessary scope of access;
• binding to a specific project;
• the separation of reading from changing;
• explicit confirmation of sensitive actions;
• a prohibition on reading secrets automatically;
• a restriction on network destinations;
• a revocable token;
• a distinction between a blocking rule and a warning;
• the logging of significant actions in the mode provided for it;
• the absence of hidden privilege escalation.

Examples of actions that may require confirmation from a human

• a change to the data schema that loses information;
• running an operation in production;
• sending context to an external model;
• creating or rotating secrets;
• calling a new external domain;
• changing the access rules;
• publishing an artifact;
• an action outside the current project.

The specific list of confirmations depends on the version and on the policy of the organization. What matters is that the user sees not only an "allow" button, but the data, the action, the purpose, and the consequences.

A secret can reach an external service by more than a prompt.

It can end up in tool output, in the diagnostics, in a log, in a crash report, in shell history, in Git, in a frontend bundle, or in a telemetry event.

Protection therefore has to cover the whole workflow.

What counts as a secret

Secrets include, among others:

• passwords;
• API keys;
• access tokens;
• refresh tokens;
• license tokens;
• private keys;
• SSH keys;
• signing secrets;
• database credentials;
• cloud credentials;
• recovery codes;
• session secrets;
• encryption keys;
• webhook secrets;
• connection strings containing a password.

The fact that a value sits in a development file does not make it safe to send to a model.

Checking the repository

Before a commit and before a project is handed over, it is useful to check for:

• known key formats;
• connection strings;
• .env;
• private keys;
• credentials added by accident;
• tokens in fixtures;
• secrets in the Git history;
• values in generated files.

A secret that is found has to be:

1. revoked or rotated;

2. removed from the current files;

3. checked against the history;

4. traced to where it was transmitted;

5. checked against the logs;

6. followed by removing the cause.

Deleting a line from the latest commit does not make an exposed secret safe.

MCP and secrets

For every MCP tool it is necessary to determine:

• whether it can read secrets;
• whether it can return a value;
• whether confirmation is required;
• whether redaction is applied;
• whether the result is retained;
• whether the AI client can send the result to an external model.

By default a tool must not return the live value of a secret if the task can be carried out without it.

Diagnostics

A diagnostic message has to help correct the configuration without disclosing the value.

Where a comparison is needed, a safe identifier, a fingerprint, or the last characters may be displayed, but only after a separate assessment of the risk.

Redaction

The redaction mechanism has to be applied before:

• writing to a log;
• output to the UI;
• assembling a crash report;
• sending telemetry;
• passing a tool result;
• exporting diagnostics.

Redaction has to be tested on:

• the full value;
• the value inside a URL;
• JSON;
• a stack trace;
• a multiline value;
• an encoded value;
• a partially transformed value;
• several secrets in one message.

It must not be claimed that redaction detects any unknown secret.

Local logs

Before publication a catalog of the Gabion logs has to be compiled.

For each one, determine:

• the path;
• the purpose;
• the format;
• the level;
• whether it is enabled by default;
• the data it contains;
• the maximum size;
• rotation;
• the retention period;
• the access rights;
• the deletion;
• the export.

Check separately whether the logs contain:

• file paths;
• the name of the project;
• fragments of code;
• prompts;
• model responses;
• tool calls;
• diagnostics;
• token identifiers;
• usage.

Prompt history

If Gabion does not retain prompts and responses, that has to be confirmed by a test.

If it does retain them, it is necessary to describe:

• exactly what;
• where;
• for how long;
• who can see it;
• the encryption;
• the export;
• the deletion;
• the synchronization;
• the backups.

The history of an external AI client is governed separately and must not be attributed to Gabion.

Telemetry

For every telemetry event it is necessary to determine:

• the name;
• the purpose;
• the fields;
• the identifiers;
• the endpoint;
• the processor;
• the retention period;
• the default mode;
• whether it can be disabled;
• the effect of disabling it.

Telemetry must not include:

• source code;
• business logic;
• a prompt;
• a model response;
• a secret;
• user data;
• free-text error output without redaction.

The network test for telemetry

A "telemetry disabled" mode has to be verified by observing the actual connections.

The test covers:

1. a clean installation;

2. starting the Runtime;

3. opening a project;

4. running a check;

5. reproducing an error;

6. closing the Runtime;

7. analyzing the outbound connections;

8. comparing them with the documented list of endpoints.

The absence of optional telemetry does not mean the absence of a mandatory license check or of updates. Those connections are documented separately.

Crash reports

A crash report can contain sensitive data from:

• a stack trace;
• the environment;
• paths;
• an open file;
• tool output;
• a memory dump;
• a prompt;
• a model response.

Before automatic sending, it is necessary to determine:

• whether redaction is applied;
• whether a preview is available;
• whether consent is required;
• whether it can be disabled;
• where it is sent;
• who receives it;
• the retention period.

For the client mode, a preference for automatic sending has to be a separate, deliberate decision rather than a hidden default.

The license check

A token verification request must not include:

• source code;
• prompts;
• responses;
• business logic;
• user data;
• the contents of files.

The following are documented:

• the endpoint;
• the license identifier;
• the project identifier, where one is used;
• the Runtime version;
• the result;
• the time;
• the logs;
• the retention period;
• the offline behavior.

The production application does not perform this check.

Updates

An update check can disclose:

• the Runtime version;
• the OS;
• the architecture;
• the edition;
• the channel;
• the installation identifier.

Before publication it is necessary to state:

• the endpoint;
• the frequency;
• whether the mode is automatic or manual;
• the fields sent;
• the signature of the package;
• the behavior on error;
• whether it can be disabled;
• the effect of disabling it.

An update to the Runtime must not send the code of the project automatically.

Removing Gabion

The uninstall instructions have to list:

• the binary and the Runtime;
• the configuration;
• the token;
• the cache;
• the logs;
• the crash reports;
• the downloaded updates;
• the temporary files;
• the browser data;
• local model artifacts, where Gabion managed them;
• the data that stays with external providers.

Removing Gabion must not delete the directory of the client project.

Retention

A separate period is set for each category of data:

• operational logs;
• security logs;
• usage;
• crash reports;
• support materials;
• license events;
• form submissions.

"For as long as needed" is not a defined period.

A deletion request

Before external access is opened, it is necessary to determine:

• where the request is sent;
• how identity is confirmed;
• which data can be deleted;
• which data has to be kept under a contract or by law;
• the time to completion;
• the behavior of the backups;
• the notification that it is complete.

An incident

If a secret or data has been sent in error:

1. stop any further transmission;

2. revoke the secrets;

3. identify the systems and the providers;

4. preserve the necessary evidence;

5. check the logs;

6. request deletion, where it is available;

7. assess the contractual and legal obligations;

8. notify those responsible;

9. correct the configuration;

10. run the test again.

A secret should not be masked after it is sent; it should be kept out of the prompt, the log, and the report before anything is transmitted.

One mode for models and data does not suit every project.

Before work begins, the team has to record which models are permitted, what material may be sent to them, who pays for the use, and what happens in the event of an error.

The model matrix

A model that can be connected technically does not count as permitted until it is included in the project policy.

The data matrix

For the value "restricted", a specific condition has to be stated rather than left to the interpretation of the AI.

The context matrix

For each class of task the following are determined:

• the permitted area of the project;
• the maximum set of files;
• the permitted MCP resources;
• the permitted tools;
• whether human approval is required;
• the permitted provider;
• the permitted volume of data;
• the redaction rules;
• the maximum size of the context;
• the retention period for the result.

Examples of classes of task:

• explaining code;
• a small change;
• a multi-file change;
• a schema migration;
• analyzing an error;
• work on an integration;
• documentation;
• a security-sensitive change.

The endpoint matrix

The matrix has to be built from actual network tests of the supported configuration.

The accounts and cost matrix

If exact measurement of the cost is unavailable, that is stated directly.

The log matrix

For each log the following are recorded:

• the owner;
• the path or the system;
• the contents;
• the sensitive fields;
• redaction;
• the retention period;
• rotation;
• the access;
• the export;
• the deletion;
• the backups.

The categories:

• Runtime logs;
• MCP logs;
• AI-client history;
• gateway logs;
• provider logs;
• usage;
• license events;
• crash reports;
• support materials;
• CI logs.

They must not be combined into a single line saying that no logs are retained, if even one component keeps a history.

Human approval

One of these statuses is assigned to each operation:

• prohibited;
• always requires confirmation;
• confirmation depends on the risk;
• allowed automatically.

A separate decision is required for:

• sending code to an external model;
• reading a file containing secrets;
• running a shell command;
• changing the schema;
• a destructive migration;
• access to production;
• sending a crash report;
• raising the budget;
• changing the provider;
• enabling telemetry;
• creating an external resource;
• a production deployment.

The confirmation interface has to display the data, the action, the purpose, and the consequences.

Retention

A specific period is set for each category:

If the period depends on an external provider, a reference is given to the applicable contractual terms of the specific plan.

Deletion

The project policy has to answer:

• who may request deletion;
• where the request is sent;
• how the authority is confirmed;
• which local data is deleted;
• which server-side data is deleted;
• what remains in the backups;
• what the provider is obliged to keep;
• when completion is confirmed;
• what happens after the Runtime is removed.

Removing Gabion does not delete the client project.

Incident process

The following are appointed before work begins:

• the technical contact at the client;
• a security contact;
• the contact at Pikiner;
• the owner of the LLM account;
• the owner of the gateway;
• a person with the authority to rotate secrets;
• the person who decides on notification.

The process has to describe:

1. detection;

2. stopping the transmission;

3. revoking the secrets;

4. identifying the data;

5. identifying the providers;

6. preserving the evidence;

7. deletion;

8. the legal assessment;

9. notification;

10. the correction;

11. re-verification.

Changing the policy

Changing a permitted model, an endpoint, or a category of data is a controlled technical decision.

It has to record:

• who initiated it;
• the reason;
• the old value;
• the new value;
• the date;
• the tasks affected;
• the verification;
• the approval;
• the effect on the contractual documents.

The AI must not extend its own permissions by itself.

The minimum policy before the first task

Before first use it is enough to fill in at least:

• the permitted model;
• the AI client;
• whether source code may be sent;
• the prohibition on secrets;
• whether personal data is permitted;
• the endpoint;
• the owner of the account;
• the budget;
• the maximum number of retries;
• the human approvals;
• the retention period;
• the incident contacts.

If a decision is not known, the sensitive operation stays prohibited until it is clarified.

An undefined policy is not a permission. For sensitive data it means stopping until a human decides.

The choice of an LLM does not begin with a ranking of models.

The team first has to determine:

• which tasks are passed to the AI;
• which data is permitted;
• which providers are allowed;
• whether a local mode is required;
• who owns the accounts;
• who pays for the usage;
• which limits apply;
• which actions require confirmation;
• where the logs are held;
• what happens when something is sent in error.

If you have a working product

The first step is to demonstrate the product to the Pikiner team.

The first meeting does not require sending secrets, production data, or the whole repository.

How Gabion Works FAQ on Models, Data, and the License