Build
Use the least access necessary, with non-production environments wherever practical.
MCP SECURITY, DEPLOYMENT & HANDOVER
Ship an MCP integration your team can trust and own.
KNWN builds permissions, controlled write actions, failure testing, deployment, and handover into the project from day one. The result is an integration your team can inspect, operate, and revoke without depending on us.
Server-side access checksClient-controlled productionComplete technical handover
EXAMPLE CONTROLLED ACTION
Cancel booking BK-1842, issue the €320 refund, and notify the customer.
Status
Approval requiredWaiting for user confirmation
| Check | Result |
|---|---|
| Signed-in user | Maya, Support Manager |
| Account boundary | EU Operations |
| Permission | Refunds up to €500 |
| Current booking state | Eligible for cancellation |
| Proposed change | Cancel booking and refund €320 |
Nothing has changed yet.
Confirmed result
Action completed
- Booking cancelled
- Refund submitted
- Customer notification sent
- Audit reference: ACT-1842-09
Illustrative workflow, not a customer case study.
THE CONTROL MODEL
The model can ask. Your systems still decide.
A valid tool request is not permission. KNWN keeps identity, authorization, validation, tenant boundaries, and business rules in the server and product systems that own them.
01
AI client
Proposes a defined tool call
02
MCP server
Verifies the token, scopes, audience, and input
03
Your product
Checks tenant, role, record access, and business rules
04
Approved result or clear refusal
Least necessary access
Each workflow receives only the permissions and data it needs.
Secrets stay out of the conversation
Credentials remain in runtime configuration and approved secret storage.
Minimal results
The client receives the data needed for the task, not an internal system dump.
BEFORE ANYTHING CHANGES
Make the change visible before it becomes real.
Searches and refunds should not use the same control path. KNWN separates information retrieval, preparation, confirmation, and execution according to the consequence of the action.
01.
Read
Retrieve the current record, eligibility, price, status, or availability without changing state.
02.
Prepare
Create a reviewable draft with the exact amount, recipient, fields, and expected effect.
03.
Confirm
Show the user what will happen and require approval immediately before the consequential action.
04.
Commit
Revalidate permissions and current state, execute once, and return a clear result or actionable failure.
A low-risk lookup may stop at read. A refund, deletion, booking, purchase, or external message may require the complete path.
TEST THE BOUNDARIES
A happy-path demo proves very little.
We test correct requests and the cases that should be blocked, challenged, retried, or returned as clear failures. The exact evaluation set is defined around the approved workflow.
| Test case | Expected safe behavior | Status |
|---|---|---|
| 01Expired or revoked token | Stop and request reconnection. Return no private data. | Ready |
| 02Wrong tenant or inaccessible record | Refuse the request without revealing the record. | Ready |
| 03Invalid or adversarial input | Reject or normalize it before any action reaches the product. | Ready |
| 04Duplicate confirmation | Prevent an unintended second write. | Ready |
| 05Upstream timeout or partial failure | Return a clear failed or unresolved state, never a false success. | Ready |
| 06Prompt injection inside retrieved content | Treat the content as untrusted and never let it expand the user's permissions. | Ready |
Ready.
Evaluation results, known limitations, and recovery behavior become part of the handover rather than disappearing after the demo.
PRODUCTION OWNERSHIP
Production runs in an environment your team controls.
We prepare the integration for the agreed cloud account, network, identity provider, deployment process, logging, and monitoring setup. KNWN hosting is not required.
YOUR CLOUD ACCOUNT
- MCP server
- Identity provider connection
- Product APIs and data sources
- Secrets manager
- Logs and monitoring
- Health checks
KNWNTime-limited access
Access is narrow, approved, and removableKNWN access lifecycle
Launch
Use temporary production access only when deployment or verification requires it and the client has approved it.
Handover
Remove KNWN users, rotate or revoke temporary credentials, confirm the operational owner, and document the final access state.
Some launches genuinely require temporary production access. It is agreed in advance, kept narrow, and removed or rotated at handover.
OWNERSHIP MEANS OPERABILITY
A repository is not a handover.
Code without deployment context, tests, and operating instructions leaves the client dependent on the original developer. KNWN organizes the transfer so a qualified engineer can understand, deploy, verify, and operate the agreed build.
project/source/deployment/tests/evaluations/docs/architecture-and-data-flow.mdauthentication-and-permissions.mdenvironment-and-secrets-map.mdoperations-runbook.mdknown-limitations.md
- Dependency lockfiles and build instructions
- Logging, monitoring, health, and rollback guidance
- Live or recorded handover session
- Named client-side operational owner
No mandatory KNWN hosting or Studio subscription. Ongoing support is optional and scoped separately.
SECURITY AND HANDOVER FAQ
Questions teams ask before allowing an integration into production.
Clear answers before access or deployment begins.
Is an MCP server secure by default?
No. MCP defines a way for clients and servers to exchange capabilities, but the security of a production implementation still depends on authentication, authorization, input validation, data minimization, write controls, secret handling, deployment, logging, and testing. KNWN designs those controls around the approved workflows and the client's existing systems.
How are users authenticated?
For remote integrations that access customer-specific data or write actions, we normally connect the client's existing identity provider through an OAuth 2.1 flow supported by the target client. The MCP server validates the token, intended audience, expiry, and required scopes on every protected request.
Does ChatGPT or another MCP client enforce our permissions?
No. A client can help identify tools, request account connection, and present confirmation prompts, but the MCP server and product backend must still enforce scopes, tenant boundaries, role checks, record access, validation, and business rules for every call.
Will KNWN need production credentials?
Not for the first conversation or initial workflow design. Some projects require temporary access to staging or production for deployment and verification. Any access is agreed in scope, limited to the task, and removed or rotated during handover.
Can KNWN deploy into our cloud account?
Yes. KNWN can prepare and deploy the agreed integration into a client-controlled AWS, Azure, Google Cloud, or other supported environment. The exact network and hosting model depends on the target clients, existing architecture, and publication requirements.
What exactly is included in the handover?
The agreed package can include the source repository, dependency lockfiles, architecture and data-flow documentation, authentication and permission model, deployment configuration, environment requirements, tests, evaluation scenarios, secrets inventory without secret values, runbook, known limitations, and a live or recorded handover session.
What happens to KNWN access after handover?
Temporary KNWN users, tokens, keys, and deployment permissions are identified during the project. At handover, the client removes or revokes that access, rotates credentials where required, and confirms the person or team responsible for production operation.
Are penetration testing or compliance certification included?
Not by default. KNWN includes the implementation, testing, and documentation defined in the project scope. Formal compliance certification, legal advice, independent penetration testing, and continuous security operations require separate scope and appropriately qualified specialists.
Is ongoing support required?
No. The build is delivered for client ownership and operation. Support for incidents, client changes, new tools, protocol updates, or wider evaluations is optional and quoted separately.
DEFINE THE BOUNDARIES EARLY
Tell us what the integration may read, change, and send.
Bring the workflow, the users, the source systems, the actions that need approval, and the environment where production should run. We will turn those boundaries into the architecture and project scope.
You do not need to share production credentials for the first conversation.