Home·Security

For your security review.

Ajutant is built on the principle that your data stays in your tenant, your identity provider governs access, and you can prove what happened at every step. This page answers the questions your security team is going to ask.

Written for the CISO, the security architect, and the assessor. Architectural depth is in the architecture page; this page focuses on the controls.

01·Tenant isolation

Your data lives in your Azure subscription. All of it.

There is no Ajutant-hosted control plane your traffic passes through, and no shared backend where your data sits alongside another customer's. Every component is deployed into resources we provision inside your subscription, governed by your tenant's policies.

Where is our data stored?
In your Azure subscription. Application state, user records, audit logs, vector indexes for grounding: all in resources you own, in the region you nominate. No content, logs or diagnostics are sent to us. The only data we receive is summarised token usage per model, to reconcile billing, and statistical quality metrics.
Can Ajutant see our data?
We don't use our access to read your content. Ajutant runs in a subscription (or a single resource group) in your tenant that you give our deployment identity access to, so we can deploy and update the platform. You can see what it does in your Azure activity log, and you can review, restrict or revoke that access at any time. If we ever need to look at something operational, we ask you first.
Is there a shared multi-tenant database?
No. Each customer's deployment is a separate set of resources in a separate subscription. There is no path by which customer A's data could be queried from customer B's deployment, because the two deployments share no infrastructure.
Where does data go for model inference?
To a model endpoint you choose: Azure-resident (recommended; data stays within Azure under your contract with Microsoft), or an external provider you have contracted directly with. Either way, the inference contract is between you and the provider, not us.
What happens to data if we end the contract?
Nothing leaves. The platform and its data are already in your tenant. You can stop using it, decommission the resources, or keep operating the deployment, whichever fits your situation. There is no Ajutant-side data to retrieve or destroy.
02·Identity and access

Authentication and authorisation come from your directory.

Ajutant doesn't issue user accounts. Authentication is delegated to your Entra ID, and access decisions inside the platform are made against the same group memberships you already manage.

How do users authenticate?
Through your Entra ID, using whatever sign-in posture you already enforce: SSO, MFA, conditional access. We don't issue passwords or maintain a parallel user store. If a user can't sign into your tenant, they can't sign into Ajutant.
How is access to specific assistants and data scoped?
By Entra ID group membership. An assistant can be scoped to a single team, a department, or the whole organisation, whichever group rules you apply. Users only see the assistants their groups grant access to.
What happens when someone leaves?
Off-boarding in your directory off-boards them here. There is no separate Ajutant user list to keep in sync. Group changes propagate at the next authentication.
Who can administer the platform?
Administrative roles inside Ajutant (publishing an assistant, reading audit logs, adjusting governance) are themselves scoped against directory groups you control. You decide who holds each role; you can revoke any role through your normal directory process.
Does Ajutant have any administrative access?
To the Azure resources Ajutant runs on, yes: that is how we deploy and update it. You grant that access, it is limited to Ajutant's own subscription or resource group, and it shows up in your Azure activity log. We tell you about every release in advance. Nothing we do happens silently.
03·Audit and traceability

Every request, recorded, in your own logging stack.

Audit and operational telemetry feed into Azure Log Analytics in your tenant. Retention, access, and forwarding to your SIEM are governed by your existing policies. There is no separate audit system to integrate.

What is logged?
Every request: who asked, which assistant, when, what grounding sources were consulted, what model was called, what the response was, and any user reaction to it. Plus administrative events: who published or modified an assistant, who changed a permission, who pulled the kill switch.
Where do the logs go?
Azure Log Analytics in your tenant. From there your existing forwarding rules can pipe them to your SIEM, your data warehouse, or wherever security telemetry already lives in your organisation.
How long are logs retained?
By your retention policy on Log Analytics, not ours. Most regulated customers run 12 months online with longer archival; configure as you would for any other workload.
Can a user see their own audit trail?
Yes, scoped to their own interactions. Administrators with the audit role see across teams, governed by the group rules you've defined.
Can audit logs be deleted by anyone in our organisation?
Log Analytics retention and deletion are governed by your Azure RBAC, not by Ajutant. We do not provide any in-product mechanism to truncate or alter the audit feed.
04·Operational controls

The levers you'll want to pull.

A platform that can't be stopped, scoped, or escalated isn't governed. These are the controls Ajutant provides out of the box, and how they fit into existing incident workflows.

Is there a kill switch?
Yes, at two levels. Per-assistant: any administrator with the right role can disable a single assistant instantly. Platform-wide: the same role can stop all assistants. Both are auditable, both take effect immediately, neither requires a support ticket.
How is the acceptable use policy enforced?
At the point of use, not just on paper. Your AUP gate sits between the user and the assistant, enforcing the rules you've set: prohibited content categories, sensitive topics, output formats. Violations are logged and (by your policy) blocked.
Are there PII guardrails?
Yes. Detection runs before content reaches a model, with configurable actions: redact, block, or warn. Detection is conservative by design; you can extend the rules for your own sensitive categories.
What controls cost?
Per-team cost caps. Every use case has a visible cost in your tenant, and the runtime stops calling models against a team that has hit its cap until the cap is raised or reset. Costs are metered against your own Azure spend, not bundled into a licence.
What happens if a user reports an ethical or correctness issue?
It routes to your IT Operations team in real time, not to us, and not to the model provider. Improvement signal (was this useful, time saved, what went wrong) routes to the team that owns the assistant; serious issues escalate immediately to IT Ops, who can pull the assistant or open an incident.
05·Model providers and data residency

You choose the model. You hold the contract.

Your content leaves your tenant boundary only when it is sent to a model provider you have chosen and contracted with directly (or to web search, if you switch it on). The terms governing what the provider can do with your inputs are between you and the provider, not us.

Which models can we use?
The major commercial and open models, never a model of ours: Azure-resident models (GPT via Azure OpenAI Service and Azure AI Foundry), external providers under your enterprise contract (Anthropic Claude, Google Gemini, and others via their own APIs), or open-weight models such as Llama through Azure AI Foundry. The choice is yours, and you can route different workloads to different models.
Does inference data leave Azure?
Only if you choose a provider whose endpoint sits outside Azure. Azure-resident models keep inference inside Azure under your existing Microsoft contract, including data residency commitments. If data residency matters to you, choose an Azure-resident model.
Are our prompts used to train the provider's next model?
That depends on your contract with the provider, not on us. Enterprise contracts with Azure OpenAI, Anthropic, and OpenAI all support no-training terms; consumer or developer-tier contracts may not. We help you confirm what's in place during deployment.
Can we change models later?
Yes. The runtime calls models through a stable interface, so you can swap the model behind any workload without changing the platform, the assistants, or the governance. Useful when a provider changes terms, prices, or capability.
06·Incident response

What we commit to if something goes wrong.

Honesty about incidents matters more than promising a number we couldn't always hit. Here is our posture, in plain terms.

If we detect a problem in our deployment, what should we do first?
Use the platform-wide kill switch if the problem is severe. Then contact us via your designated support channel. Because the platform runs in your tenant, you have full incident control before we are involved.
If Ajutant has a security incident, when will we hear?
As soon as we know it could affect a customer deployment, contact named in your deployment agreement is notified directly, in writing, before any public statement. We commit to providing facts as we have them, not waiting for a tidy narrative.
What about an incident in our supply chain (a model provider, Azure)?
We monitor public advisories from upstream providers and flag any we believe affect customer deployments. We are not a substitute for your own monitoring of those providers, but we will not stay silent if we think something needs your attention.
Do you offer a vulnerability disclosure programme?
Yes. Responsible disclosure to [email protected] (subject line "Security"). We commit to acknowledging within two working days and providing a substantive response within ten.

For procurement and risk teams

If you need our written security posture, a deployment-specific risk assessment, or sight of our incident response plan for your due diligence, we share these directly during the discovery process. They are not gated; they are simply not the right thing to publish on a public webpage.

07·Certifications, and what we don't yet claim

Honesty about stage.

Most vendor security pages list certifications. We're going to be direct about where we are. Ajutant is founder-led and working with early customers; the certification posture reflects that stage. We'd rather be plain about it than imply scale we haven't earned.

Where we are today

  • Architecture designed to the requirements of an ISO 27001 control environment, even though we do not yet hold certification
  • Deployment patterns aligned with Microsoft's published Azure security baselines for the services we use
  • Vulnerability disclosure programme operating
  • Founder-led operations with documented internal controls

What we do not yet hold

  • ISO 27001 / 27017 / 27018 certification
  • SOC 2 Type II attestation
  • Cyber Essentials Plus
  • Independent penetration test reports as a standing artefact (we commission per-deployment when the customer needs one)

The reason this is a smaller gap than it looks: the platform runs in your tenant, on your infrastructure, under your access controls. The certifications above primarily attest to a vendor's handling of customer data in the vendor's environment. Because we do not host your data, host your identities, or run shared infrastructure on your behalf, the surface area those certifications address is materially smaller for us than it would be for a SaaS vendor on a shared backend.

We are also clear-eyed that certifications matter beyond their direct scope. They are a signal of operational maturity. We are willing to walk a procurement team through our internal controls, our risk register, and our roadmap to formal certification, in detail, during your evaluation. We will not, at any point, claim a certification we do not hold.

If your procurement process requires a formal certification

Tell us in the discovery call. We will be honest about the timeline to meet that requirement, and whether we can do so for your engagement. Sometimes the right answer will be "not yet"; we would rather lose the deal than fail an audit.

08·Vendor continuity

Your deployment doesn't depend on us.

Founder-led is a deliberate choice. For a regulated buyer evaluating a small vendor, the right question isn't whether you trust us. It is what happens to your deployment if we don't exist tomorrow. Here is the honest answer.

It runs in your tenant, not ours
The platform runs inside your Azure tenant. It keeps running whether we exist or not. There is no shared service of ours that your deployment needs in order to run.
The infrastructure is auditable, and yours
The deployment is delivered as Bicep that your own IT team can read, audit, and modify. There is no black box you are renting access to; the infrastructure is yours.
Source escrow on request
For enterprise contracts, source code escrow is available on request. Your continuity rights survive any change in our circumstances.

We are early-stage, and honest about that. We are not asking you to trust that we will be here forever. We are showing you why your deployment does not need us to be.

Bring your security team. We'll answer their questions.

A 30-minute discovery call is the right next step. Bring whichever colleagues need to be there: IT, security, procurement, risk. We answer the questions a webpage can't.

Book a 30-minute discovery call