Building applications

AI and MCP

Scoped human grants, approved AI clients, reviewable change sets, and server-enforced authorization.

v1 design baseline. This page specifies intended behavior. Delivery and validation are tracked in the implementation plan; it is not a claim that the platform is already implemented.

Primary model

Users use their approved Claude, ChatGPT, or Codex account.

The AI client connects to:

https://mcp.intrnl.cloud/mcp

The inference cost remains with the user’s or the organization’s AI subscription/contract.

intrnl charges for:

Application hosting
Builds
Databases
KV
Governance
Security
Runtime capacity
Support

It does not need to absorb every code-generation token.

Both OpenAI and Anthropic support remote MCP-style tool access with authenticated endpoints. OpenAI’s guidance explicitly says authorization must be enforced by the MCP server on every request rather than delegated to the model; Anthropic’s connector supports remote HTTPS servers and OAuth bearer tokens. OpenAI MCP server authorization, Anthropic MCP connector

No subscription-token proxying

Do not implement:

Paste your Claude session cookie
Login to Claude inside intrnl
Give intrnl your ChatGPT subscription token
Run Claude Code using a user’s consumer session from our servers

The valid architecture is:

User’s AI client
        ↓
authenticated MCP call
        ↓
intrnl tool

A future native intrnl assistant may use API billing and become a separate paid offering.

OAuth grant model

An MCP grant is bound to:

human user
organization
AI client
allowed applications
scopes
issued time
expiration
revocation state

Example scopes:

profile:read
apps:read
apps:create
source:read
source:write
builds:read
builds:create
previews:create
deployments:request
deployments:approve
security:read
security:admin
secrets:reference

Normal AI-client grants must not include:

deployments:approve
security:admin
identity:admin
secrets:read

secrets:reference allows an AI to configure code around a named capability without obtaining the underlying secret value.

Tool surface

Use a small set of obvious core tools plus a searchable operation catalog.

Core tools

profile.get
organizations.get_current

apps.list
apps.get
apps.create

source.list_files
source.read_file
source.apply_patch
source.get_diff

builds.create
builds.get
builds.get_logs

previews.create
previews.get

deployments.request
deployments.get

operations.search
operations.execute

The search/execute pattern keeps the default tool list manageable while supporting future capabilities.

Every operation schema is versioned and generated from the same command definitions used by REST and Filament.

AI change-set model

AI does not directly mutate production.

Human prompt
    ↓
AI requests source change
    ↓
intrnl creates or updates a change set
    ↓
patch applied against expected base revision
    ↓
commit/checkpoint
    ↓
build
    ↓
preview
    ↓
human review
    ↓
deployment request

Optimistic concurrency prevents the AI from silently overwriting changes made after it read the source.

Each change records:

Human actor: Jane Smith
Agent/client: Claude
OAuth grant: grant_...
Organization: Example Organization
Application: Equipment Requests
Base revision: abc123
Result revision: def456

The audit text should read:

Jane Smith, via Claude, modified Equipment Requests.

Not:

Claude modified Equipment Requests.

The human grant is the authority.

No AI approvals

An AI may:

Create an app
Read and edit permitted source
Run a build
Create a preview
Explain a diff
Request deployment
Request a capability

An AI may not:

Approve its own deployment
Approve a destructive migration
Grant itself network access
Grant itself a secret
Change mandatory organization policy
Add itself to another application
Change its OAuth scopes
Approve regulated status

Public MCP endpoint and organization networking

Cloud-hosted AI clients connect from the AI provider’s infrastructure, which has different IP addresses from the user’s office network.

Therefore, mcp.intrnl.cloud cannot be limited solely to organization office IP addresses if the organization wants cloud-hosted AI clients to use it.

The endpoint should be publicly reachable but protected by:

OAuth
Client registration
User and org authorization
Short token lifetimes
Scope enforcement
Rate limiting
mTLS where supported
Revocation
Audit
Optional provider IP checks as supplemental protection

An IP allowlist is not a substitute for authentication and authorization. OpenAI’s own MCP guidance makes that distinction. OpenAI MCP authentication

Data-classification controls

The organization configures approved AI clients and account types.

Example:

Organization allows:
- approved ChatGPT Enterprise workspace
- approved Claude Enterprise workspace

Organization denies:
- personal AI accounts for organization source
- all AI clients for regulated apps

For the pilot:

No regulated data in prompts
No regulated data in source
No sensitive production data in previews
No enterprise system integrations
Synthetic data only
Explicit “No regulated data” classification and user acknowledgement

Do not log full AI prompts by default. Log:

Tool name
Authenticated actor
Inputs necessary for audit
Source patch/diff
Result and error metadata
Correlation ID

Avoid storing unrelated conversational text that may contain sensitive data.

Compatibility validation

Remote MCP support does not establish that every client, account tier, transport, or workspace policy works with intrnl. The Phase 0 MCP spike must verify representative OpenAI and Anthropic clients, OAuth discovery, grants, revocation, and audit.

The read-only MCP tools exposed by this documentation site are a separate service. They do not implement the planned authenticated platform endpoint at mcp.intrnl.cloud. See documentation access.

Threat model

Threats and controls for tenant isolation, untrusted code, AI access, identity, and recovery.

Source control

Managed Forgejo repositories, change sets, GitHub canonical mode, and full-history transfer.