Security posture
What this server can and cannot do to your data
Five absolutes. Read-only by default. Every write tool is individually scoped. Every write requires a dry-run first. Every action writes an audit-log entry. And there are no destructive deletes, ever. The first four are engineering; the fifth is contractual, and it is the one we will refuse work over. A server cannot fix the model that calls it, but it can bound the blast radius, and that boundary is what this page describes in full.
Default posture: read-only
A new server ships read-only. Turning on a write capability is a deliberate, per-tool decision made with you and recorded in the signed manifest, not a global switch someone flips later. Most internal builds never enable a write at all, because most of what a team wants from Claude is to ask questions of a system it already trusts, and reading answers those questions without adding a single unit of risk.
The write-tool gate
Every write tool passes four gates before it ships: a scope, a required dry-run, an audit entry, and the no-delete rule. The registry rejects a write tool that is missing any of them.
function registerWrite(tool: WriteTool) {
if (!tool.scope) throw new Error("write tool needs an explicit scope");
if (!tool.dryRun) throw new Error("write tool must support dry-run");
if (tool.destructive) throw new Error("destructive deletes are refused");
return audited(tool); // every call writes a log entry
}Prompt injection: the honest section
This is the part most vendors skip, so it is the part worth reading. A malicious instruction can arrive inside a document, a database row, or a tool description, and a server cannot stop the model from reading it. What a server can do is make the damage bounded and visible rather than silent and open-ended.
Contractor isolation
Portkeel is deliberately small, and implementation runs through a vetted contractor bench. Contractors receive sandbox credentials only. Production secrets never leave our infrastructure, this is contractual rather than a norm, and the founder reviews every line before it reaches a production deploy.
Incident policy, written before it is needed
If a server we run is involved in an incident, we disclose within 24 hours and share a post-mortem. Concealment is what actually ends companies here, not the incident.
What we are not
We are not a penetration test, not a security audit, and not a compliance certification. There is no SOC 2 today. If your procurement needs one now, we are not your vendor this quarter, and stating that plainly is cheaper for both of us than discovering it in week six.
Security questions
- Can the server delete our data?
- No. There are no destructive deletes, ever, and that is a contractual absolute rather than a configurable setting. A tool may archive or flag a record; it may not remove one. If a use case genuinely needs a hard delete, we are not the right vendor for that tool, and we say so before the manifest is signed.
- How do you handle prompt injection?
- A server cannot fix the model that reads a poisoned tool description or a malicious data field; that is above its layer. What it can do is bound the blast radius: read-only defaults, per-tool scopes, dry-runs on writes, and an audit log that records what was attempted. We treat injection as a containment problem, not a solved one, because as of 2026 it is not solved.
- What auth do you use?
- API keys for internal servers, OAuth 2.1 with PKCE for remote ones. Client tokens are never passed downstream, and we validate the audience claim to avoid a confused-deputy problem. The 2026-07-28 revision changed the authorization model, and every server we run negotiates the current revision.
- Do your contractors touch production?
- No. Contractors receive sandbox credentials only. Production secrets never leave our infrastructure, and this is written into their agreement rather than left as a norm. The founder reviews every line before it reaches a production deploy.
- Do you have SOC 2?
- No, not today, and we will not pretend otherwise. If your procurement requires a SOC 2 attestation now, we are not the right vendor for this quarter. Ask us again in 2027. What we can give you today is a published posture, an incident policy, and code you can read.
Found something, or want to ask before you buy? Write to info@portkeel.com. We reply to disclosure reports within one business day.