Security & data handling

Deployment in your environment

• We build in your tenant or cloud wherever possible: your workspace, your subscription, your repositories, under your credentials.
• That way the systems run under your platform's own access controls, identity, and policies.
• If a component has to run somewhere else, the proposal names it before work starts.

Least-privilege, read-first access

• Source connections are read-only wherever the use case allows.
• Write scopes are added one named workflow at a time, with owner sign-off.
• We build against sandbox or non-production tenants when the platform provides them, and use offline exports (such as P6 XER files) to explore without touching live systems.
• We don't need passwords or admin access to scope the work. Access is requested later, through whoever approves it on your side, and only for what the agreed work needs.

Read: Governing AI agents in construction

Credentials

• Secrets live in your server-side secret store (Azure Key Vault for production builds), owned by your account, with your renewal process.
• Never in website forms, shared screenshots, spreadsheets, desktop configs, or model prompts.
• Agents reach systems through a scoped gateway key, so they never hold upstream credentials. Each key carries its own tools, upstream auth, and rate limits.
• Production and development keys are separate. Exchanged user tokens are short-lived and scoped per operation.

Read: On-behalf-of token exchange for AI agents

Agent permissions, approvals, and audit

• The tool list is the permission boundary. An agent can't be talked into a tool it doesn't have, so we route large APIs down to the tools a task needs.
• Writes are proposals: previewed, then approved by a person. Deletes are blocked and bulk actions are capped.
• Agents act as a scoped service identity or as the signed-in user via on-behalf-of exchange, so the source system's audit trail shows the real person.
• Every tool call is logged with who, which key and server, which tool, outcome, and latency. Secrets are redacted when the log is written.
• Changes to an agent itself (prompts, tools, models) go through review, and are tested against agreed examples before a pilot widens.

Read: Hardening MCP servers for production

AI data handling

• Reporting and integration work that doesn't use an agent sends no data to an AI model provider.
• For AI workflows, you choose and approve the model provider and region. Its data terms apply to what it receives.
• We configure providers with no-training and zero or limited retention options where the provider offers them.
• Only the prompt and the context retrieved for the task are sent. Retrieved content is treated as data, never as instructions.

Read: Layered AI safety guardrails

Code and IP ownership

• Code is delivered into your repositories under version control: readable, runnable, and extendable by your team. No black boxes.
• Ownership, intellectual property, licenses, and confidentiality are set out in the written agreement and documented again at handover.
• Assessment documents are yours whether or not you choose us for the build. Public open-source components keep their own licenses.

Environments, testing, and rollback

• Pipelines, models, reports, quality rules, and infrastructure deploy from version control by script: reviewable, repeatable, reversible.
• Outputs are reconciled against your own figures within written tolerances before acceptance.
• Nothing reaches production without a named owner, a runbook, and a tested rollback. For write workflows: authorization, duplicate prevention, and a tested recovery plan.

Monitoring

• Health checks, refresh status, and data age are shown where the scope requires them.
• A failed refresh stops publishing and keeps the last good data, rather than serving wrong answers.
• Missing, duplicate, rejected, and unmapped records are visible. A gap never passes for a good result.

Read: Tracing agents with a Postgres ledger

Handover and offboarding

• Your named operating owner receives runbooks, training, and documented dependencies, licenses, asset ownership, and support responsibilities.
• You decide who holds credentials and licenses, and you remove our access when the work ends.
• Ongoing care is optional and defined in a separate written scope: named assets, support hours, severity definitions, and exclusions.