> For the complete documentation index, see [llms.txt](https://docs.lpp-minduniverse.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lpp-minduniverse.org/lingua-pactum-protocol-lpp-documentation/9.-deployment-profiles/9.2-enterprise-ai-agents.md).

# 9.2 Enterprise AI Agents

Enterprise AI agents increasingly interact with systems that already contain mature identity and access controls.

Examples include:

* internal APIs,
* databases,
* workflow engines,
* enterprise SaaS platforms,
* production systems,
* document systems,
* financial operations,
* HR systems,
* customer-data platforms,
* and administrative tools.

This creates a common but dangerous inference:

```
The agent can call the API
        ↓
therefore
the business action is authorized
```

LPP rejects that inference.

The canonical distinction is:

```
Tool Access
        ≠
Runtime Permission
        ≠
Legitimate Authority
        ≠
Constitutional Admissibility
```

#### API Access vs Action Authority

A valid API credential establishes technical access.

It does not prove that the resulting business action is legitimate.

For example, an enterprise agent may have technical permission to invoke:

```
DELETE /customer/123
```

That does not establish that:

* deletion was actually authorized,
* the correct customer was targeted,
* the instruction remains inside business scope,
* the approval is still active,
* or the action is consistent with the authorized objective.

The governance question is therefore:

> **What legitimate authority supports this specific business action?**

***

#### Business Workflow Execution

Enterprise agents may move beyond information retrieval into workflow mutation.

Examples supported by the current Authority Object domain model include:

* modifying production records,
* sending legally binding communications,
* approving procurement,
* altering HR records,
* changing customer-facing data,
* or changing internal workflow state.

These actions require more than tool availability.

An Enterprise Authority Object may bind governance information such as:

* business owner,
* workflow owner,
* system identity,
* dataset scope,
* write-permission scope,
* approval chain,
* validity window,
* change class,
* and rollback condition.

The exact production schema may vary.

The principle does not:

> **Business authority must be represented independently from technical access.**

***

#### Privileged Operations

The governance distinction becomes especially important for privileged operations.

An AI agent may possess credentials that technically allow:

* production configuration changes,
* access-control changes,
* database writes,
* account administration,
* or other privileged operations.

Those credentials answer:

```
What can the agent technically reach?
```

LPP asks:

```
What is the agent legitimately authorized
to cause now?
```

The two must remain separate.

***

#### Enterprise Admission Pattern

A representative enterprise flow is:

```
Business / Institutional Authority
        ↓
Authority Object
        +
Authorized Intent
        ↓
Enterprise Agent
        ↓
Action Candidate
        ↓
LPP Admission Kernel
        ↓
Execution Permit
        ↓
API / Workflow / Infrastructure Gate
        ↓
Business Action
        ↓
Admission Artifact
```

#### Existing Enterprise Controls Remain

LPP does not replace:

* identity providers,
* IAM,
* policy engines,
* API gateways,
* SIEM,
* enterprise logging,
* compliance systems,
* or workflow controls.

The deployable Admission Kernel model is designed to sit between AI-generated execution intent and existing execution infrastructure while relying on enterprise identity and policy metadata.

Conceptually:

```
Existing Enterprise Security
+
Layer 0 Admission
```

rather than:

```
LPP replaces enterprise security.
```

#### Deployment Forms

Existing LPP deployment specifications describe potential integration positions such as:

* middleware container,
* API gateway extension,
* agent execution wrapper,
* Kubernetes admission controller,
* or enterprise microservice.

These are reference integration patterns.

They are not requirements that every LPP deployment use the same infrastructure.

#### Enterprise Deployment Rule

The essential enterprise invariant is:

> **A valid enterprise credential may establish access, but it does not establish legitimate authority for every business action that credential can technically perform.**

***