AI Usage Policy

1. Purpose

This policy defines how Cracken personnel may use generative artificial intelligence, large language models, coding assistants and AI agents for company work. Its objectives are to obtain the productivity benefits of AI while protecting customer information, personal data, confidential information, credentials, intellectual property, software integrity and Cracken’s legal and contractual obligations.

AI assists people; it does not replace professional judgement, secure-development controls, authorisation or human accountability. The person who uses or accepts AI output remains responsible for the resulting work and actions.

2. Scope and boundary

This policy applies to all Cracken directors, employees, contractors, consultants, temporary workers and other persons using AI for Cracken work, on any company or personal device or account. It covers web applications, APIs, IDE and browser extensions, coding assistants, command-line agents, chatbots, meeting tools, plugins, connectors, retrieval systems, Model Context Protocol (MCP) servers and other systems that send information to, or act on instructions from, an AI model.

This policy primarily governs workforce use of general-purpose AI for software engineering, testing, documentation, research, analysis and related internal development activities. Production AI processing performed by the Cracken service through its approved architecture is governed separately by the product design, customer agreement, Data Processing Agreement, Privacy Policy, Sub-processor List, Data Retention Policy, access controls and secure-development procedures. Personnel must not use an ordinary workforce AI account as a substitute for an approved production data flow.

3. Definitions

• AI means a generative-AI model, large language model, coding assistant, agent or AI-enabled feature covered by this policy.
• Workforce AI tool means an AI product or account used by personnel to assist company work outside the approved Cracken production service data flow.
• Production AI processing means processing performed by the Cracken service through an approved, documented product architecture to provide the contracted service.
• Customer Data means any non-public information received from, supplied by, accessed on behalf of, or generated specifically for a customer or prospective customer, including Customer Content and Customer Personal Data as defined in the applicable agreement and DPA.
• Company-managed account means an account provisioned or controlled by Cracken and subject to its identity, access, offboarding and administrative controls.
• Approved AI Service means the exact provider, contracting entity, product, plan, account type, features and integrations recorded as approved in Cracken's Approved AI Services Register.
• Confidential information means non-public Cracken business, technical or operational information whose disclosure could harm Cracken or breach an obligation.
• Restricted information means information requiring a specifically approved workflow because of law, contract, sensitivity or security risk, including the categories listed in Section 7.
• Secret means a credential or authentication value that could permit access or impersonation, including a password, API key, token, private key or session cookie.

4. Core rules

1. No customer data: customer or prospective-customer data must not be submitted to workforce AI tools, including the corporate Claude service. This rule cannot be waived through the exception process.
2. No training or unrelated improvement: Cracken does not authorise customer data to be used to train, fine-tune, evaluate or otherwise improve a general or cross-customer AI model or service.
3. Approved and suitable accounts: Claude is Cracken’s corporate AI provider. Other providers may be used only under Section 6 and must be suitable for the information and task involved.
4. Minimum necessary context: provide only the smallest amount of non-restricted information required for the task.
5. Human accountability: verify AI output and retain normal review, testing, approval and separation-of-duties controls.
6. Least privilege: AI agents receive only the files, tools, credentials, network access and time required for the task.
7. Report mistakes promptly: accidental disclosure or unintended AI action must be reported immediately. Prompt reporting is expected and will support containment and learning.

5. Permitted uses

Subject to the restrictions in this policy, personnel may use AI to:

• explain concepts, brainstorm approaches and summarise public or approved internal material;
• draft or improve code, tests, documentation, specifications and internal communications;
• review non-customer code for quality, maintainability and potential security issues;
• create purpose-made synthetic test data that is not derived from Customer Data or real personal data and is not reasonably capable of identifying or being linked to a real customer, target, engagement or person;
• assist with debugging using sanitised examples that contain no customer data, personal data, Secrets or restricted vulnerability information;
• support research using public information, provided sources and factual claims are checked;
• operate coding agents in a controlled development environment with the safeguards in Section 10;
• design, implement and test Cracken’s approved production AI capabilities through the normal architecture, security, privacy and change-management processes.

6. Providers, accounts and approval

Cracken’s company-managed Claude service is the default provider for company work. Only the exact Claude product, plan, account type, features and integrations listed in the Approved AI Services Register are approved; the name “Claude” alone does not establish approval. Company work involving Internal or Confidential information must use a company-managed Approved AI Service.

Personnel remain eligible to choose another AI provider for public-information-only development work. A personal, consumer, free, trial or individually purchased account may be used only for Public information and non-sensitive, user-authored prompts, without access to company repositories or systems, and only when all of the following conditions are met:

• the provider is lawful and reputable and its current terms, privacy treatment and security posture are appropriate for the proposed use;
• Customer Data, personal data, Secrets, Restricted information, Confidential information, Internal information and third-party confidential information are not submitted;
• company source code and other non-public company material are not submitted or made accessible;
• model-training or service-improvement use of company inputs is disabled where the provider offers that setting;
• public sharing, unnecessary memory, plugins, connectors and broad repository access are disabled;
• the user does not accept provider terms, grant licences or connect company systems beyond the authority given to that user.

A provider’s statement that it does not train on inputs does not by itself make the provider suitable. Approval must also consider retention, deletion, human access, subprocessors, hosting and transfers, security, incident notification, account controls, connectors and contract terms. Approval applies to the complete product and data path—not only to the model name—and must be reconsidered after material changes.

Security must maintain the authoritative Approved AI Services Register. It must identify the provider, contracting entity, product and plan, approved account type, permitted information classes and features, processing locations, subprocessors, retention configuration, training and data-use terms, transfer safeguards, security assessment, business owner, approval date and next review date. An approval not recorded in the register is not valid. Privacy and Legal review is required where a service processes personal data, receives Restricted information, creates an international-transfer or employment risk, or materially changes confidentiality, ownership or licence terms.

Confidential information may be submitted only where binding provider terms prohibit use of company inputs and outputs for provider model training, general service improvement, advertising or unrelated purposes, apart from narrowly defined security or abuse processing accepted during vendor review. A user-controlled opt-out setting is supplementary and is not a substitute for suitable contractual terms.

7. Information classification and inputs

Removing a customer name is not necessarily sufficient. Pseudonymised data, distinctive vulnerability details, code, identifiers or combinations of facts may still identify a customer, person, target or confidential engagement. When classification is uncertain, do not submit the information and ask Security or Privacy.

Users must also consider information automatically supplied by an IDE, browser, terminal, repository index, plugin, connector, MCP server or retrieval feature. Hidden or automatic context is subject to the same rules as text deliberately pasted into a prompt.

Prompts, outputs, embeddings, indexes, caches, traces, screenshots and exported conversations inherit the highest classification of their source material unless an authorised owner and Privacy have documented effective anonymisation or declassification.

8. Customer data and model improvement

Customer Data may be accessed only by authorised personnel and systems for the approved customer purpose and according to least privilege. It must not be copied into a workforce AI tool for coding, debugging, summarisation, support, analysis, evaluation or convenience. This prohibition is absolute for workforce AI tools and cannot be waived under Section 17. Approval of a production Customer Data flow is not an exception: it must use the separately governed production architecture.

Cracken does not use Customer Data to train, fine-tune, evaluate, benchmark, adapt or otherwise improve any general, shared or cross-customer model, agent, dataset or service. Customer-specific production processing strictly necessary to provide the contracted service must remain within the documented, approved and tenant-controlled product architecture and the customer’s documented instructions. No employee may create a customer-derived training, evaluation or improvement dataset informally.

9. AI-assisted software development

AI-generated code is untrusted input until reviewed and validated. It must meet at least the same quality, security and licensing standards as human-written code. Before code is merged or released, the responsible developer and reviewer must, as applicable:

• understand and be able to explain the change;
• review the actual diff, not only an AI summary;
• run relevant unit, integration, end-to-end, negative and security tests;
• perform required code review, static analysis, secret scanning and dependency/vulnerability scanning;
• verify packages, APIs, citations, commands and configuration against authoritative sources;
• check generated code and dependencies for provenance, copyright, attribution and licence compatibility;
• apply stronger review to authentication, authorisation, cryptography, parsers, deserialisation, CI/CD, infrastructure, IAM, data migrations and other security-critical changes;
• preserve branch protection, required approvals, release controls and separation of duties.

AI-generated tests must not be the sole evidence that AI-generated implementation is correct. Acceptance criteria and critical test cases should be independently derived. Users must not install a hallucinated or unverified package, execute generated shell commands blindly, or interpolate AI output directly into shell, SQL, HTML, templates, infrastructure APIs or other interpreters without appropriate validation, parameterisation and encoding.

10. Coding agents, tools and autonomous actions

Repository content, web pages, issues, pull requests, documentation, source comments, test fixtures, emails, compiler output and tool or MCP responses must be treated as untrusted data that may contain prompt-injection instructions. A system prompt or an instruction to “ignore malicious content” is not a security boundary.

No instruction found in retrieved or tool-returned content may authorise an action, change the task boundary, add a network destination, request a Secret or suppress an approval. Authorisation must originate from the user or an approved deterministic policy outside model-controlled content.

AI agents must:

• if capable of executing commands or modifying files, run in an approved isolated workspace, container, virtual machine or equivalent controlled environment;
• receive access only to the task repository or an explicit file allowlist, with read-only access until a write is required;
• use short-lived, task-specific credentials supplied only to the approved tool operation where credentials are necessary; credentials must not be readable through model context, general environment enumeration, logs or tool output;
• avoid access to the user’s whole home directory, password manager, SSH agent, browser profile, production credentials, cloud administration credentials, Docker socket or unrelated repositories;
• use deny-by-default network access with task-specific destination exceptions;
• not have direct production access or permission to bypass protected branches and review gates;
• show the proposed target, parameters, command or diff before consequential approval;
• record material tool actions and approvals and operate within approved limits for runtime, cost, tool calls and recursion.

Workforce AI agents must never possess production credentials, connect directly to production or invoke production deployment or change APIs. They may prepare a reviewed change or deployment proposal. Production execution must occur through approved CI/CD or operational tooling with independently authenticated human approval and existing separation-of-duties controls.

Explicit human authorisation is required before an agent sends an external message, publishes content or packages, merges code, modifies CI/CD or IAM, grants access, makes a purchase, installs an unreviewed dependency, prepares a database migration, deletes non-production data or performs another external, destructive or difficult-to-reverse action. An AI system may not approve its own escalation or act as the sole reviewer of another AI system.

11. Factual, legal and business output

AI output may be inaccurate, incomplete, biased, fabricated or outdated. Personnel must verify material facts, citations, legal statements, security conclusions, financial information and technical claims against reliable sources. AI output is not legal, privacy, employment, accounting or security approval.

AI must not be the sole basis for decisions about recruitment, employment, performance, discipline, access, customer eligibility, legal rights, safety or other consequential matters. Proposed AI use involving personal data, employee or candidate monitoring, biometrics, emotion inference, profiling or automated consequential decisions requires prior Privacy, Security and Legal review.

Personnel must not use AI to impersonate another person, create deceptive synthetic media, fabricate evidence or conceal the use of unverified generated material. AI assistance must be disclosed where required by law, contract, publication rules or Cracken’s applicable process.

12. Intellectual property and confidentiality

Users must not ask an AI service to reproduce proprietary, paywalled, unlawfully obtained or third-party confidential material. AI output must not be assumed to be original, non-infringing, owned by Cracken or free of licence conditions. Substantial generated content or code that resembles an existing work, contains unusual notices or produces a provider code-reference match must be reviewed before use. Required copyright notices, attribution and licence texts must be preserved.

Personnel must protect Cracken’s prompts, system instructions, agents, playbooks, detection logic, evaluation methods and non-public architecture as Confidential information. Provider feedback, public chat links and support tickets must not be used to disclose such material unless the channel and purpose are approved.

13. Security, privacy and records

• Use company-managed identity, multi-factor authentication and single sign-on where available.
• Do not share AI accounts or API keys.
• Disable public conversation sharing and unnecessary connectors, plugins, memory and data-sharing features.
• Grant repository and integration access narrowly and revoke it when no longer needed.
• Do not retain raw prompts or outputs merely to monitor personnel. Any monitoring must be necessary, proportionate, access-restricted and transparent.
• Where supported, retain sufficient administrative and tool-action records to investigate incidents and demonstrate approvals without creating a new store of secrets, customer data or unnecessary personal data.
• AI-generated or AI-assisted records remain subject to the same classification, retention, access, legal-hold and deletion requirements as equivalent human-created records.

Before a workforce AI product is approved, its approval record must define and technically verify retention and deletion periods for prompts, outputs, uploaded files, repository indexes, embeddings, memories, account metadata, administrative logs, tool-action logs, backups and provider support records. These periods must be recorded in the applicable internal retention schedule. Workforce AI records must not be retained indefinitely merely because a provider default permits it.

14. Incident and near-miss reporting

Personnel must immediately stop the affected session or integration and contact security@cracken.ai if:

• Customer Data, personal data, Confidential or Restricted information, or a secret is submitted to or appears in an AI service;
• an AI agent accesses an unauthorised file, repository, system or network destination;
• prompt injection, unexpected tool use, data exfiltration or account compromise is suspected;
• an AI-generated change introduces a suspected vulnerability, backdoor, malicious dependency or material licence issue;
• an agent modifies production, IAM, CI/CD, data or an external system unexpectedly;
• a provider reports an incident or appears to retain, share or train on information contrary to the approved arrangement.

Immediately prevent further disclosure or action, but do not delete chats, logs or other evidence unless Security directs it. The initial report should identify the provider, product and account, time, affected data or systems, prompt or tool action, sharing settings and containment already performed. Security must open an incident record and apply the Breach-Response Policy, including assessment of customer, contractual, regulatory and data-subject notification requirements.

Do not rely on deleting a chat as proof that provider copies were deleted. Security will coordinate containment, evidence preservation, credential revocation or rotation, provider contact, data and notification assessment, reversion, remediation and lessons learned with Privacy, Legal, Engineering and the relevant data owner.

15. Prohibited uses

Personnel must not use AI to:

• circumvent this policy, security controls, access controls, review gates, provider restrictions or law;
• submit Customer Data or secrets through an ordinary workforce AI workflow;
• conduct unauthorised security testing, exploitation, persistence, malware activity, surveillance or data collection;
• generate or release knowingly deceptive, discriminatory, harassing, illegal or unsafe material;
• make unreviewed production changes or other consequential external actions;
• make a consequential decision about a person without the required human process and prior review;
• misrepresent generated output, citations, test results, approvals or evidence as independently verified;
• use personal accounts or unapproved integrations to evade company administration or contractual safeguards;
• use AI in a way that infringes intellectual-property, privacy, confidentiality or contractual rights.

16. Product AI development and change management

A new or materially changed AI capability in the Cracken product must follow the normal product, architecture, security, privacy, legal and change-management processes. The responsible team must document the intended purpose, provider and model dependencies, data flows, system instructions, retrieval sources, tools, access, retention, known limitations, human oversight and fallback behaviour.

Before release and after material changes to a model, provider, prompt, dataset, retrieval source, tool or permission, the team must apply risk-appropriate testing for security, privacy, accuracy, misuse, prompt injection, data exfiltration, excessive agency and failure modes. Customer-facing AI must use staged deployment, monitoring, abuse controls, rollback and incident procedures appropriate to the risk. Workforce tools and personal provider accounts must not be connected directly to production customer data.

17. Training, responsibilities and exceptions

Security and Engineering leadership own this policy and the approved-provider process. Privacy and Legal support reviews involving personal data, customer obligations, intellectual property, employment use, international transfers or legal interpretation. Managers are responsible for ensuring that personnel understand the rules relevant to their roles.

AI users must complete role-appropriate training covering permitted tools and data, confidentiality, hallucinations, bias, intellectual property, secure development, prompt injection, agent permissions, output verification and incident reporting. Developer and administrator training must address the additional risks of integrations and autonomous tools. Training should be refreshed after material changes and periodically according to risk.

An exception must be approved in writing before use by the relevant Security or Engineering owner and, where applicable, Privacy and Legal. The exception must identify the business purpose, information, system, owner, safeguards, duration and expiry. No exception may authorise unlawful processing or use outside Cracken’s contractual authority. No exception may authorise Customer Data or Secrets to be submitted to a workforce AI tool; a proposed production flow involving Customer Data must be reviewed and governed under Section 16.

18. Compliance, review and enforcement

Failure to follow this policy may result in removal of AI access, containment or remediation measures, and disciplinary or contractual action consistent with applicable law and Cracken procedures. Cracken encourages immediate reporting of mistakes and near misses; concealment or continued unsafe use may increase the severity of the response.

This policy must be reviewed at least annually and after a material AI incident, provider or model change, product-architecture change, regulatory change or significant change to the information Cracken processes. Provider terms and settings must be checked when a tool is approved and periodically thereafter.

19. Contacts

Security questions and incident reports: security@cracken.ai

Privacy questions: privacy@cracken.ai

Legal questions: legal@cracken.ai

Appendix A — Reference framework

This policy was informed by the following authoritative or widely adopted guidance. These sources support risk management and secure practice; they do not all create legal obligations for Cracken in every circumstance.

• UK Information Commissioner’s Office, Guidance on AI and Data Protection: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
• UK Information Commissioner’s Office, AI and Data Protection Risk Toolkit: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/ai-and-data-protection-risk-toolkit/
• UK National Cyber Security Centre, Guidelines for Secure AI System Development: https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
• UK National Cyber Security Centre, Prompt Injection Is Not SQL Injection: https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
• NIST AI Risk Management Framework 1.0, NIST AI 100-1: https://doi.org/10.6028/NIST.AI.100-1
• NIST Generative Artificial Intelligence Profile, NIST AI 600-1: https://doi.org/10.6028/NIST.AI.600-1
• NIST Secure Software Development Practices for Generative AI and Dual-Use Foundation Models, SP 800-218A: https://doi.org/10.6028/NIST.SP.800-218A
• OWASP Top 10 for Large Language Model Applications: https://genai.owasp.org/llm-top-10/
• Regulation (EU) 2024/1689 (EU Artificial Intelligence Act), including AI-literacy and relevant deployer obligations where applicable: https://eur-lex.europa.eu/eli/reg/2024/1689/oj