Agentic AI Guidelines

This document is intended to describe some of the complexity around Agentic AI risk and mitigations within University systems. This document assumes that Agentic AI tools are not prohibited by policy and will need to be restricted. 

This document does not:

• address Penn users accessing systems external to the University.

• assess the utility that risk must be balanced against.

• Address locally contained Agentic use that doesn’t access multiple systems.

This document also assumes that users are intended to be held accountable for any actions taken on their behalf by Agentic AI. 

The assumption of accountability is based in part on legal definitions set forth in the Uniform Electronic Transactions Act (UETA). Specifically provisions regarding electronic agents are likewise applicable within Penn systems and that a user is accountable for any agentic action taken on their behalf.  From the UETA:

A contract or other record relating to a transaction in or affecting interstate or foreign commerce may not be denied legal effect, validity, or enforceability solely because its formation, creation, or delivery involved the action of one or more electronic agents so long as the action of any such electronic agent is legally attributable to the person to be bound

Terms

Some terms not otherwise defined in this document are covered here to ensure understanding of the term as it relates to this document.

• Agentic AI: catch all term for any machine learning system that takes some meaningful action on behalf of a user, either via specific invocation of a process or by accessing protected (moderate or above data classification) data on a user’s behalf.

• Agentic AI System: A service or installation of Agentic AI operator that can action and access resources on behalf of a user.

• Agentic AI Instance: An account with an Agentic AI Service. A given instance may have contractual protections while another does not.

• Agency: refers to the scope of actions an AI system is permitted and enabled to take within the operating environment, and how much a human bounds an agent’s actions or capabilities. (as per language from The Agentic AI Security Scoping Matrix: A framework for securing autonomous AI systems)

• Autonomy: refers to the degree of independent decision-making and action the system can take without human intervention. (as per language from The Agentic AI Security Scoping Matrix: A framework for securing autonomous AI systems)

• Computer Use Agent: An agentic tool that is not embedded in a service but operates at a “computer” level, interacting with systems much as a human user of an endpoint would. They may leverage MCP tooling, or operate through a standard User Interface. Other terms include but are not limited to:

  • Computer Using Agent

  • AI Operator

  • AI Browser Agent

• Human-In-The-Loop: the process by which Agentic AI asks for consent before taking select actions. Some systems use the LLM itself to decide which actions require consent.

• Model Context Protocol (MCP): An interface associated with a service offering endpoints for access to data or functionality that the service provides. This interface is scoped to appropriate components of the service and allows delegating least permissions for least time.

Summary

Agentic AI services offer utility and risk beyond the known and managed automations available in our environment. Leveraging these services responsibly requires understanding both the intended and unintended impact of incorporating Agentic AI workflows.

Agentic AI is likely accessing our systems today with no reliable means of detection. Unmanaged tools may actively be extracting data. While these tools are not approved for use neither has training been required for the users who may inadvertently been exposing data.

When users do leverage Agentic tools those users should have the training, documentation and appropriate tooling to adopt best practice. Services enabling Agentic AI should support best practice through an MCP layer. This should include at the minimum the ability to grant least privilege for minimal durations to authorized users from appropriate systems.

Auditing appropriate access and protecting against known Agentic threat models requires robust and integrated visibility from the source of requests through to the fulfillment.

User level controls are insufficient to protect Moderate PII/FERPA Data. Destination systems cannot reliably detect agentic access when it occurs. In order to adequately protect these systems both user-level and system-level controls must be in place. 

Agentic AI Instances should not retain Moderate PII/FERPA data. Transferring data from Destination systems can undermine control and ownership of the data lifecycle.

Systems not authorizing Agentic AI access still have a necessity to protect against it.

Assertions

The following assertions are used as to frame the recommendations that follow. 

Agentic AI must be contractually prevented from training on University Data.

More specifically, third party Agentic AI must be prevented from using University Data that could potentially, even if only in a failure state, be exposed to non-university agents.

As per the Privacy & Contracts provision of Penn AI Guidance:

Avoid sharing personal or sensitive data with the tool and should not input moderate or high-risk Penn data as defined by the Penn Data Risk Classification, or intellectual property, without:

1. Careful consideration and understanding of the tool’s use of Penn data and the service provider’s stated rights to the data, including, but not limited to whether the service provider offers the option to opt-out of using customer’s data to train the AI;

2. A contract in place to protect Penn data; and

3. Review by Penn’s Privacy Office and consultation with the Office of Information Security as coordinated by Procurement when moderate or high-risk data is involved. 

Consultation with the Penn Center for Innovation, where intellectual property is involved.

The language, as with much Penn language, is broad and allows for some level of local interpretation. Based on Wharton’s capacities the desired interpretation would be that:

Moderate, moderate PII/FERPA or High must not be used with an Agentic AI System or with an Agentic AI Instance that has not received a risk review through the Wharton Information Security Office and contractual review through University Procurement under guidance by Penn’s Privacy Office with additional review as necessary. This is true even if the provider states that they don’t train on data.

While this is the principal dimension of review with AI providers it is not and should not be misconstrued as the only dimension. For instance, chat providers should have statements about safety monitoring and guardrails to which they can be held accountable, and what Penn’s resulting obligations are in a shared responsibility model.

Agentic AI access must not exceed the intended scope of the authorizing user.

One of the risks with Agentic AI systems is the ability to discern training or augmenting data via specifically crafted requests. To safeguard against unauthorized access an agentic tool must not have access to any data or processes that the user themselves would not have access to.

Users should be able to scope the permissions and duration of Agentic AI access and authorization must be easily revokable.

Common guidance for Agentic authorization is not to offer open access to services but to authorize the completion of task across systems, or authorize each privileged action. These authorizations should come with a time-bound component sufficient only to achieve the outcome. Barring a sufficiently narrow time-bound component a known path for users and administrators to revoke authorization must be established in line with the destination service’s risk tolerance.

Agentic AI must not operate on a user's behalf without consent.

As users are accountable for activities of an agent operating on their behalf, users must have awareness of both the possibility of agentic actions being taken and fully informed of the agency they are consenting to. 

No service should offer agentic functionality without full disclosure to the user of the presence of such functionality, the agency and autonomy of said system, particularly any integration between systems. This awareness should also include language informing the user of their responsibilities based on the capabilities of the agent.

An agent must make clear to a user the action[s] it will take and require acceptance of that activity.

Destination Systems must be able to define Agentic AI access policies, including prohibiting use.

Destination systems are under obligation to provide safeguards to protect the data they host and the processes they enable. These services may be required by University policy, federal or state guidelines or the specifics of Data Use Agreements to preclude access to Agentic AI systems or LLMs or to restrict the scope of their access. These services may need to know the capacities of source Agentic AI Instances to in order to approve access.

Recommendations

Governance

Policy, standards and/or guidelines should be leveraged to mitigate the user behavior derived risks to the institution and our digital assets. Ideally the widest appropriate policy should define appropriate and inappropriate access, this may be up to and including the University’s Acceptable Use of Electronic Resources or IT Security Policies. While Wharton could implement a standard to hold Wharton constituents to, control is better aligned to the University level where the full constituency of PennKey can be addressed.

Direct Policy

A direct policy would read like:

“Users may only use Agentic AI to access systems or data through mechanisms explicitly intended and documented to support that access. A PennKey user session is NOT an appropriate mechanism to access to Penn systems and is prohibited.”

At a minimum, unauthorized access, if detected, should result in loss of access to the targeted systems or data until appropriate remediation is identified.

Indirect Policy

As AI tools are maturing, as are controls and authorization models, the above guidance may be subject to change. It may be best to have a policy reference supporting standards or guidelines. This would allow for a binding policy but being able to delegate the updating of the standard or guideline independently from the policy.

In this case the policy would read:

“Users may only use Agentic AI to access systems or data in accordance to the practices defined in the the Agentic AI Use Guidelines”

Which would be coupled with language:

• “Users may not grant Agentic AI access to their PennKey user session through computer use mechanisms or otherwise”
• “Users may access select PennKey systems from documented supported endpoints that require PennKey authentication to verify access.”
• Users should also be precluded from using Agentic AI to connect to Penn systems that don’t assert that they support agentic use.

Standards

Agentic AI Instances

• Adherence to the Data Classification and Management Standard scoped to the data they may access.
• Detailed logging including authorizing user, authorizing action, success or failure of request, destination system.
• Logging to a centralized logging repository to allow correlation with destination systems.
• PennKey SSO authentication.
• The ability to revoke user session tokens must be in place.
• Review of new features and capacities to ensure that emerging functionality continues to comply with appropriate standards.
• Appropriate IAM tooling must be in place to revoke access.
• Understanding of if the system is configured akin to OpenAI’s optional Zero Data Retention configuration.

Moderate Data Destination

• An MCP layer internal (or supplemental) to the tool requiring

  • PennKey SSO authentication

  • Logging of all requests, and access granted, duration of authorization, success or failure of request, source system.

  • Logging to a centralized logging repository to allow correlation with source [and destination] systems.

  • The ability to scope access granted

• Least privilege enabled for all users via PennKey

• Logging of all requests, user granting access, nature of the request and success or failure

• The ability to correlate logged requests to source and MCP layers to ensure requests come from authorized instances of Agentic AI systems.

• Alerting for access to the system that can’t be correlated to approved Agentic AI instances.

• Defined policies for blocking access and addressing unapproved access.

• Appropriate IAM tooling must be in place to revoke access.

Moderate PII/FERPA Data [or higher] Destination

• Access to the system must come from sufficiently controlled endpoints or services.

• Access to the service must come from an authorized user.

• Appropriate IAM tooling must be in place to revoke access across all component systems collectively.

• Agentic AI Instances must have Zero Data Retention configurations so that copies of data from the destination system are not maintained.

Moderate PII/FERPA Data [or higher] Destination

• Restrict access to managed endpoints that preclude the installation/execution of agentic software.

• Prohibit integration with services allowing agentic access.

• Offer alternative controls and mitigations approved by an appropriate risk owner.

Data Classification Exposure from Destination System MCPs

* this prohibition is dependent on if we institutionally have the need to forget users on request from a GDPR/CCPA perspective, or otherwise, within the retention period of the platform.

Protections

Destination systems need to provide safeguards for allowed agentic access, controls against inappropriate use and detection where able.

Mitigations

Robots.txt/meta tags

Robots.txt should be leveraged for web interfaces and to indicate if LLM/Agentic access is appropriate at all. While robots.txt allows for wildcard instructions, those instructions are more often ignored than specific blocks. Resources like github.com/ai-robots-txt/ai.robots.txt include collections of crawler agents. Local web logs can also be reviewed for agent listing to block based on detected behaviors. 

Where robots.txt is meant to control if automated systems can crawl content meta tags general governing indexing content that is exposed. Meta tags like:

<meta name="robots" content="noai"> and <meta name="robots" content="noimageai">

The meta tags project desired behaviors but don’t ensure them. 

Robots.txt and meta tags should be configured for all managed sites with explicit instructions for AI appropriate to the application. Traditionally, sites behind authentication would not have required this configuration as robots would not normally have been authenticated. Agentic use makes this an invalid assumption that should be addressed as content is refreshed.

Controls

Reauthentication

Existing controls on Workday and some other sensitive systems require authenticating again within an SSO session to gain access to a system. This configured would preclude a hostile user agent from using an existing SSO session to gain access to these systems without user assistance. Reauthentication should be considered for all systems with Moderate PII/FERPA data and required for systems with high data.

WAF/WebServer Configuration

Ideally our systems allow for controls in-depth with a Web Application Firewall before unwanted agents can even reach them. Web Application Firewalls can be configured to block many of the known actors and to allow for common configurations that can be updated centrally and shared between resources. AWS provides guidance on this tooling for their WAF offering. 

Alternately local Apache/NGINX controls may be implemented in lieu of WAF.

These blocks are likely based around IP and User-Agent controls and can be used to block agent patterns without any approved uses. Approving an agent configuration for use would allow unapproved uses of that agent to bypass these controls.

As some computer-use agents, like OpenClaw can leverage the user’s browser and IP these controls are only partially effective.

Device Management

While not all destination systems can effectively restrict the devices that can access them many can and should. Access to moderate PII/FERPA could be restricted to institutionally owned devices with only approved software. Doing so, could prevent the installation of untrusted software (like a malicious agent), and ensures detective controls like CrowdStrike have an opportunity to intervene before systems are exposed. Additionally or alternately, CrowdStrike could be used to block execution of known agents. This access would be best coupled with Mutual TLS configurations requiring a certificate on the device authorizing the device to connect to the managed system prior to verifying user authentication to the same system.

Detection

There is not a bullet proof detection method. Computer use AI agents leveraging a user's local device equate to a threat model akin to a malicious internal actor where only some of their activities are suspect. Detecting UI behaviors a human couldn’t replicate will catch some traffic, but many agents mimic human patterns. A well behaved Agent should not solve a CAPTCHA but some will. 

That does not make detection efforts useless, and they can be combined to increase the likelihood of detecting malicious patterns.

Logging

Logging activities is an essential baseline. We need the capacity to coordinate events across managed systems so that the absence of upstream source event can be used to identify requests coming from unmanaged systems.

Moreover, as Agentic AI Instance logs and destination logs must be available collectively to detect and respond to patterns. The staff responsible for this assessment may be independent of the staff assigned to either the source or destination systems. This staffing needs to be identified and assigned based on our risk tolerance for response. This will require log analysis capabilities, building dashboards and known response plans for undesired access across source and destination systems.

Ideally, if the details of an Agentic request and it’s fulfillment are defined in a comparable manner in logs we can protect against known vulnerabilities in AI systems, protecting the institution and the staff. 

Alternately, the capacity to get the specifics of the request and/or results, and having sufficient logging to establish that they happened and were related may be the best we can get and respect the privacy of the request.

Analytics

To get deeper into AI detections and potentially to indicate sufficient protections we may need to integrate more traditional analytics tooling into the security detection space. Page behaviors are the most effective means of identifying agents that have bypassed our other efforts. vouched.id/learn/blog/how-to-detect-ai-agent As these are generally beyond what we offer today, this should be considered only for the most sensitive data that might be exposed to not trained and bound by policy.

Virtuous Path

Establishing a virtuous path, or optimal configuration, can help address the needs that drive agentic efforts in a supportable manner. It is not reasonable for a typical user, even with training, to be able to make a determination of appropriate controls across systems. We have to provide resources clearly denoting acceptable paths and preclude behaviors that stray reinforced through training.

This virtuous path is based on the capacities we have today. There is an emerging technical landscape that comes with additional risks and new capacities. If a particular model is adopted for a virtual path, it must be reviewed and renewed on a cadence appropriate to the institutions need to respond. Quarterly or annually would be recommended.

User Behavior

Training

Users should be informed of the liability they personally adopt when interacting with University systems with AI tools. There are numerous paths where an uninformed user may make a series of reasonable decisions and expose University data. Informing users is accomplished through training, documentation and policy.

Training Content

• Reinforce legal obligations, applicable policies and standards, (particularly Data Classification and Management).

• Establish how to generate deterministic outputs for review and retention.

  • Management should identify what outputs need to be retained.

• Rely on human-in-the-loop for any activity when judgement may be required.

  • How to balance “approval fatigue” and the requirements for human-in-the-loop.

  • How managers have to provide space and actively require appropriate human-in-the-loop diligence.

  • When the Agentic System decides which activities are subject to human-it-the-loop, that is insufficient oversight without explicit risk acceptance for the data and/or systems exposed.

• Present resources for where to get help and guidance.

  • Standard locations for university and school documentation

  • Guidance for managers and employees in appropriate use, disclosure and discussion of AI use

  • Technical and procedural documentation sources for supported platforms

• Should be available for specifics of supported platforms.

• Should be available for best practice around disciplines, such as software development, information visualization, research.

  • This should include workflows intended to be implemented with AI.

  • An understanding should be identified when AI use is required, optional, or prohibited.

• Should make clear that a user won’t have enough information to determine if products or integrations are appropriate for anything more than low data.

  • However if a user has not logged in to the AI system with PennKey, it’s inappropriate to access University resources. Inversely, if they have logged in with PennKey, access is NOT automatically authorized.

Agentic AI System Management

Visibility, control and an understanding of features are necessary on Agentic AI Instances. A given Agentic AI System may be able to different standards and we need the specifics of relevant instances.

Responsible Ownership

Agentic AI Instances must receive a risk review and otherwise adhere to University policies and Wharton standards. They must implement the controls necessary to handle the data classification of any data they may access intentionally or in a failure state.

Access to Agentic AI Instances must be behind PennKey with appropriate authorization controls. 

Agentic AI Instances that retain chat history, or otherwise retain data, should not be granted access to moderate PII/FERPA data or above as the retention undermines the ability of the source systems to remove data and forget users at need.

Contractual Protections

Agentic AI Systems must have contractual protections against institutional data being used to train the models or otherwise facilitate intentional or unintentional sharing of data. If the service offers chat capacities, we must understand the shared obligation around safety response, detections and response. The collection of safety response practice and guardrails for the service must meet our requirements. 

Logging

Agentic AI Systems must generate logs for any agentic requests. Logs should indicate the activity or access authorized, the duration of that authorization and the user doing the authorization and the system connected to. If variable methods of authorization are allowed the method of authorization must also be noted.

These logs should be collected in LogScale.

User Awareness

Users should be presented with the appropriate information of the agentic systems features as well as the user’s own responsibilities. 

At a minimum users should be informed of:

• destination system approved to access from the Agentic AI Instance.

• how to connect to those destination systems. 

• how they will be notified of changes to their responsibilities and system changes.

This information should be available at, or before, initial login as well as being able to be referenced at need.

Destination Systems

Destination systems should present an alternate path for agentic access than UI experience for users. This alternate path ensures the ability to distinguish between direct user access and agentic access.

Responsible Ownership

Destination Systems must receive a risk review with a scope inclusive of allowing agentic access either on submission or as a scope change. Systems must adhere to University Policies and Wharton Standards.

An MCP must be provided (or other technical controls ensuring differentiation of agent and user) that grants access to only appropriate functionality and data, and the data classification exposed is known and understood. Appropriate logging must be in place.

MCP Interfaces

Services should present a Model Context Protocol (MCP) interface if they wish to facilitate Agentic or LLM access in general. 

The MCP service[s] should:

• Require PennKey authentication to delegate access to the agentic system or LLM.

• Should restrict any access to be a subset of the delegating user’s access.

• Communicate the Scope of Consent to the authorizing user and facilitate re-authorization as necessary.

• Be able to revoke access to destination systems when the authorizing user loses direct access to said systems.

• Log all activity including timestamps, ips, authorizing user’s pennkey, target system accessed, scope of access granted, data categories actually accessed or processes invoked, success or failure status of requests. These logs should be consolidated in logscale.

• Require the user to attest that the system they are connecting from is an approved and managed instance of a platform. In practice, a user connecting from ChatGPT should have to assert they are connecting from the Penn Managed ChatGPT instance and not a personally paid for or the commercial free instance.

• Provide any other service specific context on appropriate use before authorizing the user.

An MCP service[s] should not:

• Present any access to High data by intent, nor should there be a failure state that could accidentally expose high data.

• Allow any access if the institutional risk that a trained user might connect an unmanaged Agentic AI Instance is not acceptable.

Logging

Destination systems should generate logs from any agentic requests. 

Logs should indicate:

• The activity or access authorized

• The duration of that authorization and the user doing the authorization

• The MCP agent or agents involved

• The action ultimately taken

• If variable methods of authorization are allowed the method of authorization must also be noted.

These logs should be consolidated in LogScale.

Agentic Ecosystem Management

Visibility

Destination Systems should be able to trace requests back through any MCP layers to the calling Agentic Source System. This requires responsible teams to have access across source, MCP and destination logs. Requests with visibility across all systems are auditable and can be evaluated to ensure the request and it’s authorizations align with the access that was ultimately granted and the nature of the response. This is a mechanism to detect hidden prompt injections and other attack mechanisms.

Requests at destination systems that can’t be traced back to source system provide incomplete visibility and are likely symptoms of misconfiguration or policy violations. These should be reviewed and responded to based on the risk of the systems destination systems involved.

Requests from source systems that don’t align with destination systems may indicate potential exfiltration of data, misconfiguration, or policy violations. These should be reviewed and responded to based on the risk of the source systems involved.

* Non-Approved Agentic Access requires review and remediation.

Staffing

Staffing has to be assigned to establish detection, auto-remediation and alerting across the ecosystem based on risk tolerance and potential data exposure. This staffing needs visibility into logging or alternative functionality that will allow tracing an agentic request from it’s source system to it’s destination systems and provide the metadata one what was authorized, what was executed.

As the Penn ecosystem is broad, the capacity for this visibility may be a limiting factor for the scope of integration. The team responsible for the response for any destination system must have access to the logs from all source, MCP or otherwise intermediate systems.

An Agentic Tool from Wharton’s managed ChatGPT instances accessing a hypothetical MCP layer for Canvas would require support from a team with access to view logs for ChatGPT, the MCP layer and Canvas itself and have the staffing to take actions on inappropriate access within a risk accepted length of time.

Known Risk Considerations

Managed systems are generally only available to faculty and Staff. Student access is presumed to come from unmanaged endpoints. For these endpoints, the above recommendations would permit a student user access to FERPA data systems, such as Canvas. These systems will likely have to allow access and contend with the possibility of Computer Use models. Additional efforts need to be made with vendors in these cases to ensure WAF and logging, and if possible other detection tools. Moreover, it is more important to reinforce the fact that agentic use in a PennKey session is inappropriate and that there will be consequences if it’s identified.

This same concern exists for Bring Your Own Device models, or access from unmanaged institutional devices.

Additionally, while Wharton might implement process blocking with CrowdStrike to prevent Computer Use tools on devices that can access Moderate PII/FERPA data, not all users who access Wharton Moderate PII/FERPA data will necessarily have a Wharton managed endpoint.

We have to know, track and accept the risks. We will rely on emerging standards and tools to help mitigate and review 

Conclusion

Agentic AI is in the wild today and we need to adjust our stance to address the risks it poses to our environment. Agentic AI can operate in an manner that augments the authorizing user, or it can operate in a manner that imitates the authorizing user. Imitation of users by Agentic AI is a risk to both our systems and our users. Unapproved Agentic AI makes a bad actor of a legitimate user, often inadvertently.

Computer Use is one of the terms used to describe the user imitation behavior, but there’s not a single standard language for it and it may not be immediately obvious to users. To responsibly handle this complexity we must make it clear that there are inappropriate uses, provide training that helps identify them, and provide clear directions to approved offerings and configurations.

We have to have the appropriate tooling in place on destination systems and the staffing to ensure that we are safeguarding our data through detection and response.