SAP and NVIDIA OpenShell: Govern AI Agents at Runtime
Assess AI agent authorization and runtime isolation together when sensitive data or core systems are involved. Check identity, data export and traceability. Confirm formal integration scope, performance and certification against current evidence.
Verify Actual Delivery Beyond Project Announcements
SAP disclosed on September 28, 2026 that it is jointly developing with NVIDIA. SAP engineers are participating in the construction of OpenShell code and promoting its embedding into the SAP Business AI Platform. The focus of this development is to connect the agent's execution environment with the enterprise's existing authorization, identity management and auditing requirements.
The widespread availability of OpenShell is the backdrop for this announcement; its complete integration with the SAP platform is another judgement. Enterprises can study executive-level governance based on this, but they should still check the actual integration capabilities provided before purchasing or going online to avoid treating the work in progress as a function that has been delivered.
Authorization Permits Actions; Isolation Limits Their Scope
Joule Studio determines whether the action is allowed before the request enters runtime based on the role policy, business policy and process context. The runtime here is the environment in which the agent actually performs tasks. OpenShell focuses on constraining this environment: what the agent can see, do, and where to send inferences.
The questions answered by these two layers are different. Being allowed to read procurement information does not mean that the agent should read all related documents; being allowed to prepare quotations does not mean that it is allowed to send quotations. Only by converting business permissions into executable access boundaries can the approval intent continue to take effect during task running.
| governance dimension | Business authorization side | runtime boundary side |
|---|---|---|
| Action qualification | Determine whether the request is executable based on the position, policy and current process | Constrain the scope of data and operations that permitted tasks actually come into contact with |
| Responsibility and traceability | Preserve licensing rationale and business context | Connect the execution track and check whether the actual behavior is consistent with the authorization |
| where the reasoning goes | Identify which business data is allowed to be used for tasks | Restrict processing destinations and verify compliance with existing data policies |
Manufacturing companies should dismantle the pilot scope from sensitive actions
If the agent only assists in querying ERP information, you can first limit the reading range and observe whether it will expand access along with related data. If the task involves procurement modification or quotation sending, the corresponding approval should be retained, so that the agent identity corresponds to the approval action, and then test whether the ultra-authorized request will be blocked. These are pilot path suggestions and do not imply full control of the integration.
Cross-system processes are particularly prone to permission gaps. For example, the purchasing system may allow reading of data, but the customer system may grant write permissions that are too wide. The pilot can reproduce this link with a sample that does not contain real sensitive information to see which link the rejection occurred and whether business changes have occurred before.
When selecting pilot actions, prioritize tasks that limit the scope of impact and make it easy to check the results. If you must rely on integrated features that have not yet been verified to prevent high-risk operations, you should first reduce the scope of the task or maintain manual execution; after the permission link and failure handling are verified, you can then consider expanding authorization.
Use actual execution records to check whether governance is up to date
When evaluating OpenShell AI agent management, you can separate normal tasks, unauthorized requests, and interruption scenarios. In this way, we can find out whether the identity is lost, whether the data bypasses the scheduled exit, and whether the log only records the beginning but no result. Testing should use controlled samples and check with the enterprise's existing IAM; IAM is the mechanism for managing identities and access rights.
During the inspection, evidence can be collected around the following controls, each corresponding to a different location of failure:
- Agent identity: Check the execution subject in each system record to confirm that the responsible subject who initiated the task can be traced.
- Minimum permissions: Submit read or modification requests beyond the scope of the task and observe whether they are rejected to avoid sharing accounts with wide permissions.
- Data export: Track the data transmission path, and block and verify destination attempts that are not within the approved range.
- Inference location: Check the environment where the processing request actually arrives, and check whether sensitive data remains within the allowed range according to corporate policy.
- Audit logs: Correlate authorization decisions, tool calls and business results to verify whether investigators can restore the action process.
- Stop mechanism: revoke permission or issue a stop request while the task is running, and check whether subsequent calls continue to occur.
- Failure rollback: Simulate an interruption in a recoverable sample process and verify the changes performed, the recovery method and the legacy state.
Isolation has value, but authentication and business recovery cannot be presumed
Runtime isolation helps tighten execution boundaries, but it does not automatically determine whether a purchase is reasonable, nor does it guarantee that written business data can be recovered. If the authorization itself is too broad, the agent may still make incorrect actions within the scope of the permission; if the external system has submitted changes, stopping the agent may not undo that submission.
Therefore, when rejection, disconnection, or interruption occurs, you should first locate the impact by comparing logs and business status. If it cannot be proven that unauthorized actions have been blocked, first fill in the corresponding permissions or execution boundaries; if the changes have taken effect, proceed according to the verified business recovery plan, and maintain a smaller pilot scope if recovery capabilities are insufficient.
FedRAMP, FIPS, and regulated industry capabilities are commitment roadmaps and cannot be written as certifications that have been achieved or that current projects have met compliance requirements. For regulated enterprises, the valid certificate, scope of application and configuration of this project should be checked before entering the formal business process. The coverage and performance of formal integration also need to be judged based on actual delivery materials and test results.
Prepare these information and then decide how to enter the core system
Before starting the pilot, you can sort out the specific actions to be handed over to the agent, the data involved, the existing position permissions, the system call chain, and the manual approvals that must be retained. Then add samples, log fields, abnormal observation records and recovery methods that can be used for testing, so that business and technical personnel can evaluate the same task.
After obtaining this information, you can decide whether to perform restricted queries first or test operations with approval; you can also identify which actions should continue to be processed manually. If multiple solutions pass the same tasks and acceptance targets, then compare the verification investment, daily maintenance, exception handling and actual delivery boundaries to make executive-level governance a condition for sustainable operations.