--- title: "Sign Where You Work: Introducing the XI Objects Connector API" description: "Cryptographic provenance shouldn't require a separate app. The XI Objects Connector API brings signing and verification into the tools your team already uses." author: "I.Livingston - Co-Founder" published: 2026-03-09T04:00:00+00:00 updated: 2026-03-09T16:29:27.205374+00:00 tags: ["announcement", "api", "connector", "documents", "provenance", "signing"] url: https://xiobjects.com/articles/sign-where-you-work source: XI Objects --- ![One click to sign. One click to verify. The Connector API handles everything in between.](https://stxiopublic.blob.core.windows.net/content/sign-where-you-work/5d32b1e677363846cf460e47694b8e5451e9583a05249235e2666ea35c633b03.webp#xi=79F7EB334EB3FFC212B48E1F2734819B6DFF7DE361EF2061D028BB51DF5F6C97) Every tool in your workflow produces artifacts. Word documents, spreadsheets, design files, build outputs, PDFs. They move between people and systems constantly, and none of them can answer a basic question: has this been changed since the author signed off on it? The problem isn't that cryptographic signing is hard. The problem is that it lives in the wrong place. Separate tools, separate workflows, separate steps that people skip because they break the flow of actual work. The **XI Objects Connector API** puts signing and verification where they belong: inside the tools you already use. --- ## One API, Every Tool ![Your desk has a dozen tools. The Connector API gives all of them provenance.](https://stxiopublic.blob.core.windows.net/content/sign-where-you-work/1cc393718b079124bfbb487ba9046f0378ee5d286de8f5d23a328f85b67ba1b6.webp#xi=76548FAA8A4BDA3008450EDC2AB053152DEDDD4AFC12338039095CA556ABAA50) The Connector API is a single service that any application can call to sign, verify, and attribute files. Word, Excel, Photoshop, CI pipelines, custom internal tools. The signing, the certificate management, the identity resolution, all of it happens behind one consistent API surface. Each file format gets its own lightweight connector library that knows how to extract content and embed a trust block in a way that's native to that format. The Connector API handles everything else: keys, certificates, attribution, and publishing signing records to the Orbital network. Adding a new format doesn't mean rebuilding the stack. It means writing one small library. Word is the first connector we shipped. More are coming. --- ## Provenance That Travels With the File ![A signed Word document with trust verified inside the application.](https://stxiopublic.blob.core.windows.net/content/sign-where-you-work/9713fa6409b0bc362b28a266a7b02317eee9464df43061355d3acfb49f38b4da.webp#xi=0934A70EBA24D49B877F3C46CE11C77EEE65595D0BF7C66D6147E1A2C2D586E5) When you sign a file through the Connector API, the cryptographic proof gets embedded directly into the file itself. Not as sidecar metadata that gets stripped on upload. Not as a detached signature that lives in a separate system. The trust block is part of the document. Rename it, email it, upload it to SharePoint, copy it to a USB drive. The proof follows. Anyone can verify a signed file with a single API call. The Connector recomputes the content hash, validates the signature, and resolves the signer's identity through Orbital. No account required. The file carries everything a verifier needs. --- ## No PKI Headaches Certificates provision themselves. The first time someone signs a file, the Connector API generates their key pair, obtains a certificate from the XI Objects trust infrastructure, and handles renewal automatically from that point forward. No certificate requests, no IT tickets, no keystore configuration. Users don't even know it's happening. The tradeoff isn't security. Leaf certificates are short-lived, valid for up to 24 hours, and renewed transparently before they expire. If a key is compromised, an admin can revoke it immediately. Short-lived certs mean the blast radius of a stolen credential is measured in hours, not months. --- ## From Solo Developer to Enterprise Deploy it however your team works. A standalone executable on a laptop. A Docker container serving an entire organization. A Windows service running in the background. The same API, the same key management, the same verification, regardless of how it's hosted. An admin creates API keys and distributes them to the team. Users configure their plugin once and forget about it. Every person gets their own independent signing identity and provenance chain, whether that's a solo developer shipping build artifacts, an attorney at a firm finalizing contracts, or a creative at a design studio tracking project provenance. Each signer controls their own attribution profile, choosing what they share publicly: a display name, an organization, as much or as little as they want. Admins can set defaults, but the signer decides what the world sees. The trust chain always knows who signed, but the signer's public-facing identity is theirs to manage. Verification works globally, so a document signed in Denver is verifiable by a reviewer in Berlin who has never heard of your Connector instance. --- ## Provenance That Survives Into AI Every signed artifact carries attribution and provenance metadata that machines can read, not just humans. We're adopting the C2PA manifest as our attribution model across all content types. C2PA already defines a mature, well-specified structure for authorship, licensing, and AI/data-mining permissions, so rather than reinvent that, we're building on it. That means content authors can express who created something, under what license, and whether it may be used for generative AI training, inference, or data mining. Those signals don't disappear when the content enters an AI workflow. We're building the infrastructure to make them enforceable, so that authorization is applied at the content layer when documents flow into LLM-powered tools. ### Scenario: Bob in Operations Bob uses the company's internal LLM tools to accelerate his work. He asks questions, gets summaries, searches across internal knowledge. But the system only surfaces content he's actually authorized to access. Approved documents, published guidelines, materials tagged for his role. Nothing more. His queries are fast, his answers are grounded, and compliance isn't something he has to think about. Then Bob gets promoted. He joins a higher-privileged AD group. His access to AI-surfaced content expands naturally. No republishing. No permission propagation scripts. No reindexing. The content was always there, properly attributed and tagged. Bob's security posture changed, and the system respects that change immediately. Now multiply that across an organization running SharePoint. Thousands of signed documents already living in libraries, already governed by Entra ID groups and site permissions. The provenance and authorization carry forward into AI-driven workflows, so the permissions your organization already manages become the compliance boundary for AI responses. No new permission layer. No separate access control system. The infrastructure you already have just starts doing more. Signing documents is the foundation. The layers above it, provenance-aware AI workloads with authorization gating, are in active development and testing now. We'll have much more to share as these capabilities reach production readiness. --- ## What's Coming We're building connectors for Excel, Photoshop, PDF, and CI/CD runners. A GitHub Action that signs your release binaries at the end of a successful build. An Azure Pipeline task that gives your deployment artifacts the same provenance guarantees as your legal contracts. The connector contract is open and documented. If your workflow needs provenance and we haven't built a connector for it yet, you can write one. We want this to grow. Full documentation, setup guides, and the Office add-in walkthrough are coming soon. Sign where you work. Verify anywhere.