Token Observe vs Keycard
Keycard decides whether the agent gets a credential. Token Observe decides the call and then proves what the call actually did.
2 September 2026
- Keycard — product overview
- Keycard docs — how Keycard works
- Keycard docs — concepts
- Keycard docs — providers
- Keycard docs — policies
- Keycard docs — admin
- Keycard docs — audit log export
- Keycard docs — SDKs
- Keycard docs — CLI
- Keycard docs — use cases
- Keycard docs — agent-to-agent SDK
- Keycard — pricing
- Keycard blog — announcing Keycard for coding agents
Their claims, not our testing. Verify anything that decides it for you.
On this page
On agent authorisation itself, Keycard is the better purchase for most readers, and the roadmap says so before this page does
If the problem you are solving is which identity may this agent act as, and what credential should it hold for this exact tool call, buy the product whose whole surface is that question. Keycard publishes a composite identity resolved from user, device, agent and task, federated across Microsoft Entra, Okta, Google, Apple, OpenID Connect and SAML for people and across Amazon Web Services, Microsoft Azure, Google Cloud, Vercel and GitHub Actions for workloads, with mTLS, SPIFFE, Kubernetes service accounts and cloud instance IDs named on their homepage as attestation inputs. It publishes Cedar as the policy language, a default-deny posture in which every request needs an explicit permit for the user, the application and the resource, forbid rules that override permits, policy sets versioned across a zone with rollback to a known-good set, and rule authoring tested against live traffic in observe-only mode. It publishes four SDKs, a CLI that runs a policy-enforced agent session, MCP middleware, a catalogue of installable MCP servers and OAuth-protected APIs, and an A2A delegation package that exchanges a caller’s bearer token under RFC 8693 so a downstream agent inherits the original requestor’s context. Token Observe’s own market document reaches the same conclusion and records it as a constraint on what to build rather than as a marketing position: generic action passports, delegated identity and credential brokering are not open territory. Take that at face value.
The second advantage is architectural and it matters more than the feature list. Keycard sits at credential issuance and at the resource, which means it is in the path of a tool call that never goes near a model gateway — an agent hitting GitHub, Salesforce or a Postgres instance directly with a credential it was issued is inside Keycard’s model. Token Observe governs what presents a credential to its gateway: model traffic through the OpenAI, Anthropic and Gemini dialects, and tool traffic through its own MCP endpoint. Tool calls the model merely proposes are evaluated on the way back as defence in depth, but an agent that executes a tool it obtained a credential for elsewhere is not something Token Observe can refuse; the shadow-AI radar reports its existence if you have fed the radar, and nothing catches it if you have not. If most of your risk is direct API access rather than model calls, that difference decides the purchase on its own.
There is a commercial and operational gap too, and it is worth stating plainly rather than in a footnote. Keycard publishes prices: a free Starter tier with a hard cap of 5,000 transactions a month, a Team tier at $500 a month including 100,000 transactions with additional volume at $1 per 1,000, and an Enterprise tier on annual commitment that its pricing page describes as adding org-level policy, device-based policy, SCIM, Active Directory and LDAP provisioning, dedicated, BYOC or on-premises deployment, private networking, customer-managed KMS, continuous export in OCSF, 24/7 support with a dedicated customer success manager, a one-hour response SLA for P1 issues and a 99.95 per cent uptime SLA. Token Observe publishes no price list, has no SOC 2, no ISO 27001, no ISO 42001 and no independent penetration-test result, offers no availability SLA, and its licence is a template pending review by counsel rather than an executed grant. If your procurement gate is a certification or a signed uptime commitment, this comparison ends here in Keycard’s favour. Ask Keycard directly which certifications they hold, for what scope and to what date, because that is the only version of the answer worth having and this page does not hold it for them.
Token Observe and Keycard, capability by capability
The Keycard column paraphrases Keycard’s own published material as it stood on 2 September 2026. None of it has been independently tested here, products in this category ship quickly, and a capability that is absent from a vendor’s documentation is not the same thing as a capability the product lacks. Check anything that decides it for you against their own current documentation.
Where it sits
A centralised authorisation server. Their docs describe a resource issuing a challenge when credentials are absent or insufficient, the agent asking Keycard STS for authorisation, and Keycard authenticating the agent and the person it acts for before issuing.
A gateway the traffic passes through. Eleven ordered steps run in one process — authenticate, resolve agent, open trace, sanitise, scan, govern, enact, route, call upstream, govern the response, meter and record.
Neither is out of band. They are two different inline points, and an estate can hold both.
SDKs in Python, TypeScript, Go and Ruby, a CLI that runs a policy-enforced agent session, MCP server middleware, and a catalogue from which MCP servers and OAuth-protected APIs are installed.
One environment variable. For supported OpenAI-compatible, Anthropic and Gemini ingress a base-URL change is normally the whole integration, plus one Streamable HTTP endpoint for MCP.
Their docs describe an authorisation context carrying the person’s identity, authentication level and device posture, and the agent’s identity, software attestation and delegated authority. Inspection of prompt or payload content is not described in their published documentation as of 2 September 2026.
The payload itself: Unicode sanitisation, then eleven sensitive-data classes of which three are checksum-validated, then nine weighted injection heuristics scored 1.25× higher on tool results.
Their published material describes access to tools, APIs, data, MCP servers and third-party services. Governing calls to model providers is not described in their published documentation as of 2 September 2026.
First-class: OpenAI, Anthropic, Gemini, OpenRouter, Bedrock and Azure OpenAI, with identical policy, redaction, budgets and tracing enforced by a table-driven test over every provider kind.
A2A packages exchange the caller’s bearer token under RFC 8693 for a delegation token so the downstream agent receives the original requestor’s context. Their docs state these are pre-1.0 preview surfaces whose APIs may change between minor versions.
The delegation chain intersects rather than unions, so every hop must allow the action and a low-privileged agent gains nothing by routing work through a higher-privileged one.
Their site says Keycard works with every MCP client; the admin docs describe a unified access gateway exposing multiple MCP servers through a single policy-governed endpoint, and their SDK overview names discovery, token exchange, JWT and PKCE among the OAuth primitives the MCP middleware is built on.
One endpoint in front of every registered upstream server, tools namespaced and filtered to the agent’s grants, each call re-authorised at execution, and each descriptor hashed at approval so an upstream rewrite quarantines the tool.
What it enforces
Cedar, described as a declarative authorisation language that is intentionally constrained — no loops, no side effects — with policies assembled into policy sets and deployed across a zone.
A trigger, an action and a scope. Seven trigger kinds — tool and argument values, model and estimated size, spend, rate, detected data classes, injection score and source, hour of day — resolved to one verdict.
Different shapes for different jobs: Cedar expresses who may access what; the trigger model expresses what about this payload changes the answer.
Default-deny. Their policy docs state that every authorisation request needs an explicit permit for the user, the application and the resource, and that a forbid rule overrides a permit.
Deny-by-default and action-level. An action no role names is refused, and an explicit deny beats every allow wherever it is written.
Step-up. Their docs describe policy triggering additional challenges, with Keycard STS requesting step-up authentication or human approval before re-evaluating; their coding-agent post says destructive or sensitive actions trigger step-up authorisation tied to that exact context.
An approval bound to the SHA-256 of the canonical action plus its execution context, single-use through a compare-and-set, expiring at 60 minutes by default and one minute to seven days by policy. Nothing pushes it to the agent; the agent redeems it by retrying.
Their site describes authoring rules visually, testing against live traffic in observe-only mode and rolling back instantly; their docs describe versioning rules, activating a known-good set and rolling back when needed.
Shadow mode on every rule, recording what it would have done without stopping anything. Where the deployment turns the gate on, no rule may begin enforcing until a backtest of that exact rule against recorded traffic is acknowledged by a named person.
Their pricing page meters a transaction unit — issuing credentials, validating access, exchanging credentials or handling step-up — with a hard cap on the free tier. Per-agent spend ceilings or request rate limits as a policy control are not described in their published documentation as of 2 September 2026.
Hard USD ceilings per request, per rolling hour, per UTC day and per UTC month, plus requests, tool calls and tokens per minute, reserved in one per-agent transaction before egress. A budgeted route with an unpriced reachable target is refused rather than priced at zero.
Their material describes credential issuance, per-request evaluation and audit of every tool call and data access. Independent verification that the action’s effect occurred is not described in their published documentation as of 2 September 2026.
Effect contracts. A different descriptor-pinned verifier is called after dispatch, its observation must be post-dispatch and inside a freshness bound, no stage may read the action’s own response, and every postcondition and invariant must match before the run commits.
What it records
Their site claims tamper-resistant audit of every tool call and data access, structured, queryable and streaming to your SIEM in real time; the admin docs list Audit Log and Sessions, Activities, and Audit Log Export.
A hash chain over every governance-plane change, where each entry’s digest covers the previous hash plus that entry’s canonical content, so a break is reported at a named sequence number rather than somewhere.
Their published material states the property. The underlying construction is not described in their published documentation as of 2 September 2026; their pricing page lists customer-managed KMS at the Enterprise tier.
Stated in three layers, with the weakest named first: unkeyed SHA-256 by default, which an operator with write access can rewrite and recompute; HMAC-SHA256 when an off-box MAC key is configured; Ed25519 anchoring of the head to an off-box sink when a signing key is set. The verification result reports which of the three you are holding.
Tamper-evident, not tamper-proof. The claim an anchor buys is exactly one: any copy kept off-box beats any rewrite made after you took it.
Their pricing page states 7-day telemetry retention on Starter, 90-day on Team and 180-day on Enterprise with an option to extend.
Default trace retention is keep-forever, which is a storage-growth decision you make deliberately rather than a tier you buy.
Their Audit Log Export docs describe automatic export to a customer-controlled S3 bucket in OCSF v1.7.0, for integration with SIEM tools, data warehouses and custom analytics platforms; their pricing page lists continuous export (OCSF) at the Enterprise tier.
A compliance export bundling traces and events for the period, approvals with approver identity and rationale, audit entries, and a chain verification result naming any break — sealed with a SHA-256 digest at a recorded time. The bundle is not itself signed.
Not described in their published documentation as of 2 September 2026.
For a committed or compensated effect-contract run and only where a signing key exists, one canonical Ed25519 receipt binding the authority, the contract digest, the payload digests, the outcome and the audit sequence number. Verification needs a public key you already trust and nothing from Token Observe — no database read, no network call.
Their use cases describe per-user attribution in the audit log, so an action is attributable to a named individual and carries only that person’s entitlements.
The same for the record itself: trace list, search, detail and export reads are attributable, and surfaces that join records with no trustworthy team key return 403 rather than a misleading partial view.
How it deploys and what it costs
A hosted control plane with an admin console. Their pricing page lists dedicated, BYOC or on-premises deployment, private networking and customer-managed KMS at the Enterprise tier on annual commitment.
Self-hosted only, at every tier. One Node process and one SQLite file, with PostgreSQL behind the store ports as an evaluation alternative rather than a supported high-availability topology.
Their published material describes a hosted console and telemetry retained on a tier — 7 days on Starter, 90 on Team, 180 on Enterprise. What else is processed or retained is a question for their data-processing terms rather than for this page.
Nothing. No product telemetry, no phone-home, no prompts, no keys, no trace database. Governed payloads leave your network only for the model and tool providers you configure, after policy and redaction.
Short-lived tokens, brokered upstream tokens or vaulted credentials returned after access is allowed; their coding-agent post says session credentials are held in memory, never touch disk, and are reaped at the end of the session.
Provider keys stay in your deployment. Agent tokens are stored SHA-256 hashed, displayed by prefix only, revocable and expiring, with last-used recorded.
Published and metered: Starter free with a 5,000-transaction monthly hard cap, Team at $500 a month including 100,000 transactions with $1 per additional 1,000, Enterprise on custom volume and annual commitment.
No published price list. The licence is commercial source-available — use, modify and self-host, with redistribution and offering it as a competing hosted service excluded — and it is a template pending review by counsel rather than an executed grant.
Ask them which certifications and independent test results they hold, for what scope and to what date. Their pricing page publishes SSO, SCIM, Active Directory and LDAP provisioning, private networking and customer-managed KMS as tier contents.
None held: no SOC 2, no ISO 27001, no ISO 42001, no independent penetration test. What exists instead is a published residual-risk register, a published defect list naming the attacks that still work, and a licence drafted to permit a pre-purchase test with no gag clause.
Their pricing page publishes a 99.95% uptime SLA and a one-hour 24/7 response SLA for P1 issues, listed against the Enterprise tier alongside 24/7 support with a dedicated customer success manager. Which tiers that uptime figure covers is worth confirming with them.
No availability SLA, and the reason is stated rather than negotiated: the vendor does not operate your deployment and has no telemetry from it, so an uptime number from that party would be unmeasurable by either side.
Two ways to refuse an action, and what each one can see at the moment it decides
Keycard’s refusal is a withheld credential. On their published flow, the resource challenges, the agent asks Keycard’s STS, the STS authenticates the agent and the person it is acting for, evaluates policy against an authorisation context carrying identity, authentication level, device posture, software attestation and delegated authority, and then permits, denies, or raises a further challenge such as step-up authentication or a human approval. The credential that comes back is short-lived and scoped to the resource, and the resource validates it on presentation. The elegance of that design is that it composes: anything that can validate a token participates without changing, and an agent that never obtains a credential never reaches the resource at all.
Token Observe’s refusal is a typed error on a request it is already holding. The payload is in front of it, which is what makes a different class of rule expressible: block when a card number appears in the prompt, redact when a class of data is present in the response, park this exact refund on a named approver, refuse because this agent has spent its monthly ceiling. The verdict is a single point rather than a set of independent middlewares, and its order is load-bearing — Unicode sanitisation before any detector reads the string, detection before the verdict, and the on-behalf-of intersection after the verdict and before the approval branch so a human is never asked to approve something the intersection forbids.
The honest reading of the pair is that they see different things and neither substitutes for the other. Keycard’s context is rich about who and where; their published material does not describe inspecting the content of the request, and there is no reason it should, because a credential decision does not need to. Token Observe’s context is rich about what is in this payload and what it will cost; it knows far less about device posture and workload attestation, and its on-behalf-of masking is off by default and does nothing at all until an operator enables it. A buyer who needs both is not buying twice for the same thing.
- Their decision point
- Credential issuance, with a second validation at the resource. Their site puts it as: no credential without approval.
- Token Observe’s decision point
- Step 6 of eleven, before the payload leaves your network, returning one verdict — allow, block or require approval — plus a redaction plan.
- The overlap to check first
- Both are default-deny and both refuse before the action. If your estate’s tool calls all pass through MCP, run one policy set in each and decide which owns which rule rather than duplicating rules across both.
What a valid access token has not proved, and the narrow thing that follows it
An access token is a statement about authority at the moment it was minted. It says this agent, acting for this person, on this device, may call this resource for the next few minutes. It is silent on whether the call was made, whether it was made once, whether the response reflected a durable write, and whether the resulting state stayed inside the bounds the approver had in mind. Those are different questions and the gap between them is where consequential actions live: a refund API can acknowledge before the ledger write is durable, a deployment can report accepted and roll back thirty seconds later, and a timeout hides two outcomes that need opposite responses — nothing happened, or everything happened and the acknowledgement was lost. The agent framework’s default behaviour in that ambiguity is to retry, and retrying a payment is a second payment.
Effect contracts are the answer Token Observe’s roadmap actually claims, and the claim is deliberately small. A contract names an action tool and a different verifier tool by server, name and the exact SHA-256 of the approved descriptor. Before a byte leaves, a durable unique claim is taken on the business idempotency value the request already carries, so a duplicate delivery is refused rather than dispatched twice and a lost response is reconciled by calling the verifier again rather than by replaying the action. After dispatch the pinned verifier is called, its result must carry an observation timestamp that is post-dispatch and inside the contract’s freshness bound, and every postcondition and invariant must match before the run commits. The single most consequential rule in the contract language is what verification is forbidden to read: no stage after dispatch may consume the action’s own response, because the action response is exactly what a timeout loses.
The limits belong in the same paragraph as the capability. This is at-most-one dispatch from Token Observe, not distributed exactly-once execution, and the downstream system still has to honour the idempotency key it is sent. A pinned verifier is separation of role, not an independent trust authority — a genuinely independent one means putting the verifier behind a separately controlled or attested evidence source. A receipt exists only where a signing key is configured, and its anchor block is a signed reference rather than an offline inclusion proof, so an auditor who needs to prove chain coverage must obtain the anchor and chain evidence separately. Receipt-key provisioning, rotation and custody are deployment duties the product does not evidence. None of that is a reason to skip the row; it is the reason the row is written this narrowly.
- The contract language
- RFC 6901 JSON Pointers and six operators — exists, equals, not_equals, greater_than, less_than, contains. No expression language, no templates, no code, because the rejected alternative was a second plugin platform inside the governance boundary.
- Compensation is not self-reported
- A successful rollback response is recorded as accepted, never as an observation that the rollback occurred. A run reads compensated only after a fourth, separately pinned verifier proves it did.
- What the receipt binds
- Installation and receipt ids, the run id, the acting subject and team, the approval payload hash, the contract id and digest, the payload digests, the outcome state, and the audit entry’s sequence number and hash.
Coverage runs in opposite directions, which is the real reason to run both
Keycard governs the resource side. An agent calling GitHub, Salesforce, Slack, S3 or a Postgres instance with a credential Keycard issued is inside its model whether or not a model gateway was ever involved, and their use cases are written around exactly that: act as the user who asked, same agent with a different user, give an agent its own identity, revoke once and show a reviewer access stopped, allow one tool and deny the next.
Token Observe governs the model side and the MCP side. It sees the prompt, the model choice, the tokens, the cost, the tool calls that pass through its own endpoint and the tool calls the model merely proposes on the way back — which is why a rule like refunds over £200 need approval binds even when the agent executes the tool itself. What it cannot do is refuse a proposal it is never shown. An agent that obtains a credential elsewhere and calls the resource directly is caught by the shadow-AI radar if you have fed the radar, and not otherwise. The compliance mapping lists that under what the product does not evidence, and the support boundary says chasing those agents down inside your organisation is your work.
Put the two coverage statements beside each other and the pairing is obvious rather than clever. Keycard answers who this agent is and whether it may hold a credential for that resource. Token Observe answers whether this particular payload may go, what it costs, who approved it, and — for the actions with consequences — whether a second pinned tool observed that the effect actually landed. There is no shipped Keycard connector in Token Observe today, and this page does not claim one; what exists is a division of labour that does not overlap enough to make either purchase redundant.
Where each one is the right answer
Choose Keycard when
- The requirement is agent identity and credential brokering itself — composite user, device, agent and task identity, federated across your IdP and your workload identity providers, with Cedar policy and a vaulted or brokered upstream credential at the end of it.
- Most of your exposure is direct API and MCP access that never passes a model gateway, because that traffic is inside Keycard’s model and only partly inside Token Observe’s.
- Procurement needs a published price, a free tier to pilot on, a hosted control plane, a published uptime commitment and a support commitment with a named customer success manager. Token Observe publishes none of those.
- You want the enforcement point to compose with resources that already validate tokens, without putting a new fail-closed component in the path of every model call.
Choose Token Observe when
- The action has a consequence outside the gateway and you need more than a token that was valid: a pinned verifier that looked afterwards, at-most-one dispatch on the business idempotency key, and a signed receipt for the committed run.
- Model traffic is the thing you cannot see — which provider served it, what it cost, what was in the prompt, and whether a hard USD ceiling stopped it before egress rather than after the invoice.
- Self-hosted with zero vendor egress is a hard requirement, including air-gapped environments, and you would rather hold the audit chain, the MAC key and the anchor sink yourself than buy a retention tier.
- The approval has to be spendable exactly once against exactly one payload, and a retry with one argument changed must be refused as a mismatch rather than allowed as near enough.
When you would run both
Running both is the normal answer, and Token Observe’s own roadmap is written to make it the expected one: a replacement enterprise identity provider or credential vault is a named strategic non-goal, and the instruction is to federate the authoritative identity systems and attach action and effect evidence rather than recreate them. In that arrangement Keycard owns the question of which identity an agent acts as and what credential it may hold for a given resource, using the composite identity, Cedar policy and step-up flow its documentation describes, and it keeps the resource-side coverage of tool calls that never touch a model gateway. Token Observe owns the model and MCP traffic — the payload verdict, the redaction, the hard spend ceiling, the payload-bound approval — and the evidence layer that outlives both: a hash-chained audit log you can key and anchor off the box, and, for the actions with consequences, an effect contract whose pinned verifier and Ed25519 receipt say what actually happened rather than what was permitted. The honest caveat is that this is a division of labour rather than a shipped integration: there is no Keycard connector in Token Observe today, and anyone running both would be operating two policy sets and deciding which owns which rule.
The category argument sits above this one: Token Observe and ai security platforms covers what the whole category does and does not do, which is the better page to read if you have not yet shortlisted a product.
The others in the same slot
Palo Alto Prisma AIRS
Prisma AIRS decides whether the content is malicious. Token Observe decides whether the agent that sent it was allowed to.
Cisco AI Defense
AI Defense attaches a policy to an application’s connection and inspects what crosses it. Token Observe attaches permissions to an agent and decides what it may do.
Zenity
Zenity gets into the path the agents are already on. Token Observe is the path the agents are pointed at.
Noma Security
Noma decides from what the agent appears to be doing. Token Observe decides from what the agent was allowed to do, before anything is scored.
Lakera
Lakera tells your application the content is an attack. Token Observe is the thing that refuses to send it.
WitnessAI
WitnessAI stands in front of the interaction and classifies the intent. Token Observe stands in front of the API call and decides the action, its cost and its evidence.
Is Token Observe an alternative to Keycard?
Only partly, and the overlap is smaller than the category name suggests. Keycard’s published product is agent identity and credential brokering — composite user, device, agent and task identity, default-deny Cedar policy, short-lived resource-scoped credentials, step-up authorisation, MCP and A2A support. Token Observe’s roadmap names that territory as already occupied and tells the product not to compete for it. Where the two genuinely overlap is inline refusal on a tool call, and even there they refuse differently: Keycard withholds a credential, Token Observe returns a typed refusal on a payload it is holding. If agent authorisation is the requirement, Keycard is the product built for it.
What does Token Observe do that Keycard’s published material does not describe?
Three things, and each carries a limit. Effect contracts: a second descriptor-pinned tool observes the world after dispatch, no stage may read the action’s own response, a durable claim on the business idempotency key makes dispatch at-most-once, and a committed run yields an Ed25519 receipt verifiable from its own bytes and a public key you already trust — though this is at-most-one dispatch rather than distributed exactly-once, and the receipt’s anchor block is a signed reference rather than an inclusion proof. Hard USD spend ceilings per request, hour, day and month, reserved before egress, alongside request and token rate limits. And governance of model API traffic across six first-class upstreams with enforced policy equivalence. Whether any of those has since appeared in Keycard’s product is a question for Keycard; this page reflects what they published on 2 September 2026.
Both claim tamper-resistant audit. What is the difference?
Keycard states the property — tamper-resistant audit of every tool call and data access, structured, queryable and streaming to a SIEM in real time — and the construction behind it is not described in their published documentation as of 2 September 2026; ask them what it is. Token Observe publishes its construction in three layers and names the weakest first. By default the chain is unkeyed SHA-256, and an operator with write access can rewrite a row and recompute every downstream digest; the repository ships a forgery test asserting exactly that. Configure an off-box MAC key and the digests become HMAC-SHA256 with the head sealed at boot. Configure a signing key and the head is periodically signed with Ed25519 and published off the box. The verification result and every export report which of the three you are holding, because that difference is the whole guarantee. It is tamper-evident, not tamper-proof, and compliance exports are sealed with a digest rather than signed.
Can Token Observe govern a tool call that goes straight to an API?
Not directly, and this is the coverage advantage Keycard has. Token Observe governs what presents a credential to its gateway: model calls through the supported dialects and tool calls through its own MCP endpoint. A tool call the model proposes is evaluated on the way back as defence in depth, so a rule about refunds over a threshold binds even when the agent executes the tool itself — but an agent that obtains a credential elsewhere and calls the resource directly is outside the gateway. The shadow-AI radar reports that such activity exists if you feed it bills, egress logs, service-account key audits and IDE or CLI telemetry, and nothing catches it if you do not. Keycard sits at credential issuance and at the resource, which is precisely where that traffic is.
Have you tested Keycard against Token Observe?
No. Every claim about Keycard on this page is a paraphrase of their own published pages read on 2 September 2026 — the product overview, the how-it-works, concepts, policies, admin and use-case documentation, the agent-to-agent SDK page, the pricing page and the coding-agents post — and none of it has been independently tested. There has been no witnessed bake-off. Where a cell says a capability is not described in their published documentation, read that as an instruction to ask Keycard rather than as a finding: a capability that is merely undocumented reads identically to one that does not exist, and their product moves quickly. Ask them in writing, and ask for the scope and the date.
Prefer to ask a person? Write to us →
Tell us which one you are already running.
If Keycard is already in your stack, the useful question is not which to buy but what each is for, and where the seam between them sits. Say what you have and you will get a straight answer — including when the answer is that you do not need a second thing.
no form · no qualification step · no sales desk · the other three ways in