Security and Handover

A build your team can control, inspect, and operate.

Permissions, write boundaries, confirmation, failure behavior, deployment and handover are part of the build, not a pass at the end. The finished integration runs in your environment and arrives with the code, tests, configuration and documentation your team needs to run it without us.

Discuss your build

Least necessary accessExplicit write controlsClient-owned deploymentNo required hosting plan

The integration only gets the access its workflow needs.

Security starts with which workflows belong in the integration, what data each one needs, whose identity it acts under, and what it is allowed to change. Decide that late and every control after it is a patch.

We keep the surface small. No broad administrative tools, no fields the workflow never reads, no business logic copied out of your backend, and no permissions that exist only because they were convenient during development.

Users only reach what your product already allows.

Signing in establishes who is making the request. Your product still decides which account, tenant, records, fields and actions that identity may reach. We map the integration into the boundaries your systems already enforce, rather than treating one valid token as permission to do everything.

The permission model covers:

Account connection and the authorization flow
Narrow scopes, with tenant and organization context
Role and object-level permission checks
Token validation, expiry, refresh and revocation
Service-to-service identity where required
Audit events tied to the requesting identity

Reads, drafts and commits get different controls.

Read

Retrieves or computes information without creating, updating, deleting or sending data outside the conversation. A tool that sends data to another service counts as a write, even when it changes nothing in the original record.

Draft

Prepares a reviewable proposal before anything is committed. If creating the draft writes to an external system, it is still declared and controlled as a write. Draft is the business stage, not the OpenAI security classification.

Commit

Performs the approved write after validation and confirmation, and returns either a clear success reference or an actionable failure.

Consequential writes add:

Confirmation immediately before execution, with a summary of what will change
Server-side revalidation at commit time
Idempotency keys and duplicate protection
Limits on amount, frequency, object type or scope
Audit history and result identifiers

Tool annotations tell supported hosts whether an action is read-only, destructive, idempotent, or reaches outside the account boundary. They help the host apply its own approval behavior. They never replace server-side authorization, validation, idempotency and business rules.

Secrets stay in runtime configuration.

Credentials do not belong in prompts or source code. We document which secrets the build needs, where they live, how they are injected, which environment owns them, and how they are rotated or revoked. Sensitive values stay out of user-visible responses and out of logs that have no reason to hold them.

The handover documents:

Environment variables and secret references
Development, staging and production separation
Data sent to and returned from each external system
Log redaction rules
Key and token rotation procedures
Incident and access-revocation steps

We test what happens when things go wrong.

Model-generated input and retrieved content are treated as untrusted. Every tool call is validated and authorized server-side, and only the data the current task needs comes back.

The evaluation covers:

Requests that should not select the tool at all
Attempts to reach another tenant or an unauthorized record
Missing, expired or revoked authorization
Invalid and adversarial input
Duplicate writes and partial upstream success
Rate limits, timeouts and unavailable dependencies
Prompt injection in user input, retrieved content or tool output
Attempts to send data outside the account or conversation boundary
Confirmation skipped, changed or expired

The point is not to claim failure is impossible. It is to make the boundaries explicit, test the risks that actually apply, and give the system a safe, observable response when something does go wrong.

Production runs in your cloud account.

We prepare the application for the agreed cloud, account, network and deployment process. Your organization holds the production credentials and infrastructure. Nothing about the running integration depends on KNWN hosting.

The deployment handover covers:

Infrastructure or platform configuration
Build and deployment instructions, and the environment matrix
Health checks and operational endpoints
Logging and monitoring hooks
Domain, TLS and network requirements
Rollback procedure and a named operational owner

What you receive at handover.

A code archive without deployment context, test fixtures and operating instructions is not a transfer. We organize the handover around what another qualified engineer would need to understand, deploy, verify and maintain the build.

The package includes:

Source repository and dependency lockfiles
Architecture and data-flow documentation
Tool definitions, schemas, and any plugin, skill or UI assets
The authentication and permission model
Test suite and evaluation scenarios
Deployment and environment configuration
Secrets inventory, without the secret values
Runbook, known limitations, and a live or recorded handover session

Support is optional.

The project scope covers the agreed transfer and launch work. If your team later wants help with client changes, model or protocol updates, new tools, incidents or wider evaluations, we scope that separately.

There is no mandatory Studio subscription, and no requirement to keep production on KNWN infrastructure.

What this engagement does not cover.

Unless it is explicitly scoped with the appropriate qualified parties, this service does not include:

Formal compliance certification
Independent penetration testing
Legal or regulatory advice
A redesign of your entire identity or permission system
Continuous security operations or a 24-hour incident team
Indefinite operation of production infrastructure
A guarantee against every future vulnerability or platform change
Unlimited maintenance after handover

Frequently asked questions

Does KNWN certify that an MCP server is secure?

No service page can make that claim. We document the threat and permission model, implement the controls in scope, test representative cases, and record known limitations. Formal third-party audits and compliance certifications are separate work.

Will KNWN need production credentials?

The access model is agreed during architecture. We use the least access needed to build and deploy, prefer controlled environments and your own secret management, and document how access is transferred or revoked. Production credentials are not needed for the first conversation.

Can KNWN deploy into our cloud account?

Yes, when the platform and access process are in scope. The production account, credentials, billing and infrastructure stay under your control.

What happens to KNWN access after handover?

Any access we keep after handover is agreed explicitly. Anything no longer needed is removed or rotated as part of the transfer checklist. Optional support runs on separately approved access.

Are tests and evaluations included?

The suite depends on scope, but a production build should ship with automated tests and workflow evaluations for the agreed acceptance criteria, covering permissions, confirmation, invalid input and dependency failures.

Is ongoing support required?

No. Support is optional and separately scoped. You receive the agreed code, deployment assets, tests and documentation with no required KNWN hosting or support subscription.

Tell us what the integration should be allowed to do.

Bring the data it needs to reach, the actions it may take, who has to approve them, and where production should run. We will build those boundaries into the architecture and the scope.

Discuss your build