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. Nothing replicates to infrastructure we control.
Can Partner in the Loop see our data?
No standing access. We retain a deployment toolchain to push updates and a support channel you can open if you need help, neither of which has read access to your data. Any time we need to look at something operational, it requires your explicit grant and is logged in your tenant.
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 Partner in the Loop have any administrative access?
No standing administrative access. Operational support is delivered through a channel you open and close, with any actions performed against your own audit trail. 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.

Inference is the only step where data leaves your tenant boundary, and it goes to a provider endpoint you have chosen and contracted with directly. The terms governing what they can do with your inputs are between you and the provider, not us.

Which models can we use?
Azure-resident models (Azure OpenAI Service, Azure AI Foundry), external providers under your enterprise contract (Anthropic, others), or open-weight models you run yourself. 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 Partner in the Loop 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 security@partnerintheloop.com. 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. Partner in the Loop 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.

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 →