On premise AI: the open-source grant file decides the boundary

A security review of an on-premises AI deployment clears the GPU question in about a minute. Then it asks for two things the hardware never touched: the grant that let an agent read the finance system, and the record of what the agent did while it was there. Those are separate artifacts in separate places, and a review that treats them as one gets the wrong answer. On premise AI, usually written on-premises, describes a system installed and run on hardware the company itself keeps, with its own staff holding the keys and the pager. In an open-source stack the grant is a file in git, which is why it can decide whether the deployment is on-premises in any sense a reviewer cares about.

What the phrase actually claims

Premises, in the procurement sense, are the buildings and the equipment a company occupies and operates. On-premises software runs on that equipment; an on-premises AI deployment puts the model and its surroundings there too. The phrase stays almost empty until you name which part moved.

Can AI be on prem? Yes: an open-weight model on a single card answers questions from a laptop, and that has been true for years. Put an agent behind that model, and the thing a security team reviews stops being the card.

Microsoft's guide to choosing between local and cloud models is built for a feature inside one app, where the question comes down to what the device can carry and who keeps it patched (Microsoft Learn). Ask it about a system that files change requests and reads a ledger, and the frame stops fitting. The part a reviewer asks for first has nothing to do with compute: a grant file naming which agent may call which system, and the history of who changed that line. Kortix is the open-source AI Operating System: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers.

A server quote answers the easiest question

Buy a box and you have settled the card: which weights fit in memory, how many tokens a second you serve, who patches the driver on a Sunday. onprem.ai sells that scope, and says so plainly. The software "connects servers, GPUs, models, APIs, monitoring, and updates in a single environment", sold as "the complete AI stack including hardware, or just the building blocks you need" (onprem.ai).

ibl.ai makes the larger claim, the strongest one a buyer will meet here. Its on-premise platform "runs the entire AI stack — orchestration, agents, and model inference — inside infrastructure the company owns and controls", source code included (ibl.ai).

Neither page hands a reviewer the object that ends the argument. onprem.ai maps its controls to ISO 27001 and SOC 2, and a framework mapping is not a grant. ibl.ai's audit logging is one item on a feature list, nearer the deciding layer than any card specification. A reviewer wants the line that says which agent may reach the ledger, and the commit that says when the line changed.

Compute can live somewhere else

Agent work needs a machine that runs commands, and that machine is rarely the host holding the database. Kortix's self-hosting docs are blunt about it: "Sessions run on Platinum sandboxes, not on the server. The instance must be reachable from the internet so those sandboxes can call back." (the self-host docs).

The machine you keep runs the platform and holds the database behind it, along with the files sessions produce. What leaves that machine is the execution of each session, on a machine the platform creates, plus the model calls each project routes to its provider. If your rule is that nothing may connect out from an agent's machine, that rule picks your vendor list and a managed sandbox will not pass it. If your rule is that the grant and its history must remain yours, readable after the contract ends, compute location matters far less than where that file sits.

The grant file is the artifact

A Kortix project splits governance from behavior on purpose. The manifest header marks its agents: map "GOVERNANCE ONLY" and sends behavior to the agent file, whose frontmatter and body hold it. One file states what an agent may touch, the other how it thinks, and both fit in a review.

# v2 is deny-by-default: an omitted connectors/secrets/kortix_permissions/
# skills grant resolves to "none", so a scoped specialist starts locked down.
agents:
  kortix:
    file: agents/kortix.md
    connectors: all
    secrets: all
    kortix_permissions: all
    skills: all
    workspace: { project_repository: true }

  harness-reflector:
    file: agents/harness-reflector.md
    kortix_permissions: all
    skills: all
    workspace: { project_repository: true }

Two agents, two very different grants. The first holds all across the board because it is the starter. The second has no connectors: line and no secrets: line, because it reviews session transcripts. The manifest's own comment on that agent says it "gets NO connectors and NO project secrets — nothing to exfiltrate" (Kortix on GitHub). The agent that reads the riskiest material in the repo cannot reach your CRM, and the reason sits beside the grant.

Behavior is a file too. The starter's agents/kortix.md carries permission: allow in its frontmatter and names the scope a few lines down: the session "is an isolated sandbox", and "Only what you commit + push survives." (Kortix on GitHub). Per-resource permissions for people and agents. Roles, groups, and an audit trail. Scope, isolation and grant sit in the same two files, which makes them checkable instead of merely asserted.

That is the part a reviewer can verify from the repository. Session work reaches main through a change request. Merge is default-deny for agents. Widening an agent's reach, by contrast, is a one-line edit to the grant, and the docs are plain about how fast it lands: "A manifest edit takes effect when it reaches the default branch", and a dashboard, API or SDK edit commits there at once (the manifest docs). No review gate stands between the edit and its effect. The commit is what remains, and it names who widened the grant and when. Open source. Read it, fork it, audit it. Each answer traces to a file the reviewer can open, and none of them needs a support ticket.

The half you keep

A self-hosted instance is the platform itself on a machine you continue to own: "A self-hosted instance is the full Kortix platform on a server you control" (the self-host docs). Nothing in that sentence mentions a card, and that is the point of it. The instance is the half of the system a reviewer asks about, while compute is the half a vendor quotes.

Two purchases, two shapes of bill

SaaS is a subscription to software someone else operates: per seat or per credit, someone else's staff on call, and whatever the export tooling and the contract allow when you leave. On prem is capital plus recurring lines, the machine and its power, the people who run it, the work of keeping it current. The first invoice is visible. The second is why some on-prem programmes stall in year two.

The grant and the commit history behind it cost nothing to read, because they are files in the repository. The log of what agents did is a different purchase. Every action is recorded. Reading, exporting and streaming the audit log depend on the plan. The per-session audit view is an Enterprise entitlement.

What you pay for either way is the work and the person who answers for it: the upgrades, the backups, the permission review at 2am. The pager arrives with the record.

When the box is the right answer

Buy the card on your own hardware when the network is the constraint. The reasons are real: a dataset that cannot cross a boundary, a latency budget an API round trip breaks, throughput that keeps the cards busy, a model you tuned and cannot rent. Buy the runtime and the grant when the constraint is the review. When your security team asks which agent may reach the ledger, and who last changed that grant, a faster card answers neither. A file in git answers both, and its history names the change and the person. What the agent actually did on a Tuesday in March is in the audit log, which the platform records and which the plan decides you can read.

Most companies buy both, in that order. The grant file comes first, because it decides what the card is allowed to be.