Currently, the process_action and user_policy_accepted (and possibly other) methods in the core_ai\manager class are publicly accessible. This allows code outside of placement plugins  to invoke these methods directly, which could lead to unintended usage, security vulnerabilities, or maintenance challenges. And could allow plugin developers etc to circumvent parts of the AI subsystem and not get the full benefits offered by placements.

The idea of the AI subsystem is that placements and providers are the mechanisms that interact with manager. However, while this was considered at design time, due to delivery constraints with the initial implementation these were not as fully constrained as they should likely be.

To improve this situation we should look at implementing "access control" mechanisms to ensure that certain methods in the core_ai\manager class—specifically process_action and user_policy_accepted—can only be called from within placement classes. To encourage where we can using placements to interact with the subsystem instead of calling the manager methods directly. Because of the nature of PHP this can't be fully mitigated, but we should try.

This will help:

• Ensure that only classes extending the core_ai\placement abstract class can call these critical methods in the manager class.
• Enforce proper usage patterns to maintain the integrity of our AI subsystem.
• Apply a consistent access control pattern across the codebase for better readability and maintenance.

An approach to this (there are likely others):

• Modify the manager Class:

• • Change the signatures of process_action and user_policy_accepted to require a placement instance as a parameter.
  • Within these methods, verify that the caller is a valid instance of a placement class.
  • This ensures that only placements can invoke these methods.
• Update the placement Abstract Class:

• • Introduce final public methods in the placement class that act as proxies to the manager methods.
  • These methods call the corresponding manager methods, passing in $this as the placement instance.
  • Marking them as final prevents subclasses from overriding them, ensuring consistent behavior.
• Control Instantiation of Placements:

• • Make the constructor of the placement class protected to prevent direct instantiation from outside the class hierarchy.
  • Implement a PlacementFactory class responsible for creating placement instances.
  • The factory controls instantiation, ensuring only authorized code can create placements.
• Enforce Access Control:

• • By requiring a valid placement instance and controlling their creation, we prevent unauthorized code from calling restricted methods in the manager class.
  • This approach reduces the risk of unauthorized access or misuse of critical methods.