ServiceNow has introduced security engines to lock down scoped applications. The first type of security engines was Cross Scope Privilege (or Runtime Access Tracking) and the second type is Restricted Caller Access.  These both support the interactions between different scoped applications, but have distinct differences in their purpose.

Cross Scope Privilege

When ServiceNow Store was introduced, a security engine called Cross Scope Privilege (also known as Runtime Access Tracking) was introduced along with it. This engine was created to control and audit external assets that a scoped application can access. The main purpose of this engine is to allow users who install a ServiceNow Store application to view the external assets that the application is attempting to access and control whether or not the application is allowed to access those assets.

An example of this would be for a third party integration application from a security vendor who is submitting their integration application to the ServiceNow store.  They would build their application, and it would have Runtime Access Tracking (Cross Scope Privilege) set at Tracking. This will generate Cross Scope Privilege records as the application is attempting to access assets outside the scoped application.  Then when this application is submitted to the store, the Runtime Access Tracking property on the sys_store_app record will be changed to Restricted.  This will block any access to external assets from the scoped application from succeeding unless they have a Cross Scope Privilege record defined.

For most customer-created scoped applications, Cross Scope Privilege is not necessary and can cause unnecessary headaches. If you want to turn it off, you can navigate to the Scoped Application sys_app record and change Runtime Access Tracking to None.

Restricted Caller Access

A couple of years after the creation of Scoped Applications, Restricted Caller Access was introduced to solve a problem faced by the HR Application team. They wanted to restrict access to their applications and data to only certain external applications. Additionally, they wanted to create an "Application Suite" by combining a collection of Scoped Applications that would provide the functionality of the HR Application and allow separate applications to be licensed and installed as a part of a larger suite.

Restricted Caller Access was created to address this need. It controls what external assets are permitted to access a particular scoped application. By managing a record in the Restricted Caller Access table, it determines what another scope (or asset within that scope) can access within the custom scoped application. 

An example of this would be the creation of two scoped applications that need to work together, but have content that I do not want external applications (outside of those two) to have access to.  I would create the applications, and add Restricted Caller Access records to EACH of them allowing for each Scope to access the other.  That would require me to add a Restricted Caller Access record to each of those scoped applications which controls the external access to that 

Problems/Known Issues

 One thing that both of these systems require is a starting scope.  Unfortunately, at leas through Utah, when running a script from Scripts - Background, even though you choose the scope to execute it it, the Restricted Caller Access and Cross Scope Privilege engines can't find the starting scope, and will give you an error when you do not really have one in your code.  

Example:

I am testing a script include that takes an HR Profile GlideRecord (I will be adding it to a Business Rule).  I then create a script in Scripts - Background that will get an HR Profile record and pass it to my script include to test it.  If I am querying HR Profile from Scripts - Background (the actual GlideRecord query in Scripts - Background), this may cause an error from one of these engines due to the system not being able to determine the starting scope.  

Solution: Add a wrapper method that executes the HR Record GlideRecord query for you IN the Script Include you are testing.  The Script Include will always have a Scope attached to it, and the errors you receive will at least be ones that are actually a part of your code.

Code Example:

Note - the method testProfile Value takes a sys_id and executes the query for the GlideRecord, allowing for the Restricted Caller Access and Cross Scope Privilege engines to properly discern the initiating scope.

var HRProfileUpdate = Class.create();
HRProfileUpdate.prototype = {
    initialize: function() {
    },

	/*
		Test method to ensure that the method I will be executing from a
		business rule functions properly. By calling it from within the
		script include, it ensures the executing scope can be found. 

		Normally this would go in a separate testing script include as to
		not clutter the functional code.
	*/
	testProfileValue: function(sys_id){
		var grHrProfile = new GlideRecord("sn_hr_profile"); //Fake table name for example
		grHrProfile.get(sys_id);
		this.setProfileValue(grHrProfile);
	},

	/*
		
	*/
	setProfileValue: function(current /* HR Profile GlideRecord */){
		//Do Something
	},

    type: 'HRProfileUpdate'
};

For more detail on these Script Include wrappers, please see the following blog articles:

• Testing Business Rules