Security is part of execution.
Foundgine treats caller input as untrusted and carries authorization obligations into the executable plan and provider boundary.
The core invariant
Untrusted input
↓
Semantic resolution
↓
Authorization
↓
Security-preserving plan
↓
Provider conformance
↓
Execution
A successful retrieval, a valid capability description or an “allow” policy result is not enough on its own. The final executable artifact must still satisfy the security provenance established upstream.
Who owns what?
| Concern | Owner |
|---|---|
| Authentication | Host/application identity system |
| Tenant and actor context | Host/application |
| Semantic authorization | Foundgine authorization policy |
| Plan/security binding | Foundgine planning and runtime |
| Physical access | Concrete provider |
| Authority recovery | Optional control-plane infrastructure |
Authorization is layered
Caller-supplied claims cannot widen authority
Transport or client claims are untrusted input. Reserved identity keys such as role, tenant and administrator authority cannot be asserted by the caller. Accepted optional claims can only narrow an already-authorized operation.
See the semantic sample for concrete claim cases and the repository's Authorization guide for the full policy model.
Provider conformance
The provider boundary receives an executable artifact carrying security provenance. If the artifact no longer conforms to the authorized execution representation, execution must fail closed rather than silently falling back to a weaker path.
Security testing
The PenTest sample exercises the boundary through MCP and GraphQL. The advanced semantic sample covers tenant predicates, field and relationship restrictions, and adversarial caller claims.