# Designing Secure AI-based Systems:
a Multi-Vocal Literature Review

Simon Schneider  Hamburg University of Technology
Hamburg, Germany  Ananya Saha  Hamburg University of Technology
Hamburg, Germany  Emanuele Mezzi  Vrije Universiteit Amsterdam
Amsterdam, The Netherlands  Katja Tuma  Vrije Universiteit Amsterdam
Amsterdam, The Netherlands  Riccardo Scandariato  Hamburg University of
Technology
Hamburg, Germany

###### Abstract

AI-based systems leverage recent advances in the field of AI/ML by combining
traditional software systems with AI components. Applications are increasingly
being developed in this way. Software engineers can usually rely on a plethora
of supporting information on how to use and implement any given technology.
For AI-based systems, however, such information is scarce. Specifically,
guidance on how to securely design the architecture is not available to the
extent as for other systems.

We present 16 architectural security guidelines for the design of AI-based
systems that were curated via a multi-vocal literature review. The guidelines
could support practitioners with actionable advice on the secure development
of AI-based systems. Further, we mapped the guidelines to typical components
of AI-based systems and observed a high coverage where 6 out of 8 generic
components have at least one guideline associated to them.

###### Index Terms:

AI, software architecture, security, guidelines

##  I Introduction

With impactful progress in the field of AI/ML, software systems increasingly
incorporate these emerging technologies for a wide variety of use-cases [1,
2]. AI-based systems, i.e., software systems containing AI components [3, 4],
face additional security challenges [5] compared to traditional systems. The
architecture of AI-based systems is one dimension of security that needs to be
considered during their development.

Typically, software engineers can rely on an abundance of free and readily
available information on how to use specific security technology solutions
[6]. For AI-based systems, however, such guidance is limited when it comes to
the architectural design, meaning, how AI components can be integrated into a
software system’s architecture securely. Resources such as best-practice
recommendations, architectural design patterns, or similar could support
practitioners in creating more secure systems but are not yet available to the
same extent as for other types of systems.

Others identified the lack of such guidance. Mucchini and Vaidhyanathan [7]
have discussed open challenges related to the architecture design process of
AI-based systems. Lewis et al. [8] mention the creation of software
architecture practices and architecture patterns as open challenges that would
increase the security and adoption of AI-based systems.

In this paper, we present architectural security guidelines for AI-based
systems. We conducted a multi-vocal literature review (MLR) of the relevant
academic and gray literature, resulting in the curation of 16 guidelines. For
the gray literature study, we looked for relevant resources (i.e., best-
practices, design guidelines, implementation guidance, etc.) published by
organizations that are typically consulted by practitioners. For the
systematic literature review (SLR) we identified relevant academic
publications.

We address the following research questions (RQs):

RQ 1: What is the actionable guidance in the literature with regards to
designing secure AI-based systems?

We aimed to collect support provided for practitioners when designing the
architecture of AI-based systems, focusing on security. To this end, we
conducted a gray literature study and an SLR to identify existing work on the
topic.

RQ 1.1: What guidelines are suggested and from which sources?

Actionable, technical guidelines for software development activities are a
valuable asset to enhance the security of software systems. We analyzed the
results from the MLR and distilled guidelines for the architectural design of
AI-based systems.

RQ 1.2: What rationales are given as justification for introducing each
guideline?

The reasons for introducing recommendations can be diverse. To identify what
drives the formulation of such recommendations, we examined the rationales
provided for each found guideline. Such results could offer a basis to ensure
that no important requirements or stakeholders are neglected.

RQ 2: What is the coverage of the guidelines with regards to the typical
components of AI-based software systems?

We mapped the presented guidelines to the important components of AI-based
systems adapted from Kästner [9]. We identified those components that are
already addressed by the current research and those that are neglected so far.

##  II Systematic Review of Academic Literature

Figure 1: Methodology of the conducted SLR and extraction of guidelines.

Figure 1 shows the methodology we applied for the SLR. We followed established
recommendations for conducting systematic reviews [10, 11, 12] to design the
methodology. A replication package with artifacts for all steps is available
[13].

###  II-A Selection of Papers

_Scientific Databases:_ We considered four formal scientific databases as
sources for the collection of papers, Scopus, 111https://www.scopus.com Web of
Science, 222https://www.webofscience.com/wos/ ACM Digital Library,
333https://dl.acm.org/ and IEEExplore. 444https://ieeexplore.ieee.org/Xplore
They form a comprehensive set covering the majority of relevant research
papers in the domain of computer science. We had initially also examined
results on Google Scholar 555https://scholar.google.de/, but found no
additional relevant ones compared to the formal databases.

_Search String:_ To construct an appropriate search string, the two first
authors independently performed explorative searches in the databases
(following the “extraordinary attributes” suggestion for systematic reviews
presented by Ralph et al. [12]). They used search terms related to the topic
and iteratively created a list of relevant keywords, synonyms, alternative
spellings, etc. based on the findings [11]. Both authors adapted their search
strings in approximately 10 iterations and by looking at roughly 100 different
papers. Afterwards, they created the final search string together, combining
their results from the explorative searches. The final search string combines
different keywords for the scope (AI-based systems) and different keywords for
the topic (guidelines):

("ai system" OR "ai component" OR "ai enabled" OR "ai based" OR "ai empowered"
OR "ai augmented") AND (guideline* OR "best practices" OR "best-practices" OR
smell* OR rule* OR antipattern* OR "design principles")

It was adapted for the searches to fit the databases’ formatting requirements
where necessary. Figure 1 shows the number of search results for each of the
four databases.

_In- / Exclusion Criteria:_ The inclusion and exclusion criteria (IC and EC)
were constructed based on the formulated research questions. During the
explorative searches preceding the creation of the search string, we noticed
that the search results would inevitably contain many entries not relevant for
our study. This is mainly due to two reasons: (1) the domain (computer
science) could not be reliably enforced with the search parameters and because
of the use of AI technologies in diverse fields many results from other
research areas come up; and (2) the scope (AI-based systems) is hard to
enforce with the search string and many results come up that concern the AI
models and algorithms themselves instead of systems that use them. The in- and
exclusion criteria address this.

Inclusion criteria:

IC1:

The paper presents guidelines for AI-based systems.

IC2:

The guidelines concern the systems’ architecture.

Exclusion criteria:

EC1:

The paper is not in the subject area of computer science.

EC2:

The paper was not published in the last ten years.

EC3:

The paper was not published in a conference, journal, or book.

EC4:

The paper reports on a specific use-case of AI models.

EC5:

The paper considers only specific industries without generalization, e.g., the
automotive or aviation industry.

EC6:

The paper is not related to AI-based systems but, e.g., the AI models
themselves or non-AI topics.

EC1 – EC3 were realized with the databases’ search filters where possible and
subsequently checked for in the manual selection as well. The search queries
per database that include these filters can be found in the replication
package [13].

_Selection Process:_ The results of the searches in the four databases were
merged by removing duplicates based on the articles’ titles. This resulted in
a total of 1161 articles. The selection was conducted in three phases: based
on (1) title and abstract; (2) introduction and conclusion section; (3) the
complete content. This is an established process and reduces the required
effort. We aimed to ensure that no relevant articles were excluded by applying
a liberal inclusion tendency and only excluding articles that are clearly not
relevant to the study.

For each phase, two authors independently applied the criteria to each
article. We excluded articles that meet any EC in phases 1 and 2 and articles
that do not meet both IC in phase 3. A third author checked conflicts between
the first two decisions and made a final decision. Note, that we only assigned
a single EC even though multiple could apply to a paper. For each paper, we
went through the list of ECs in order and assigned it to the first one that
applied to the paper, if any. Although EC3 was meant to be enforced with
search parameters of the databases, a total of 120 results were still returned
by the searches and subsequently excluded manually.

For each phase of the SLR, we calculated the Cohen’s Kappa [14] to measure the
agreement between the two authors. We observed a substantial agreement in
phase 1 (Cohen’s Kappa of 0.70), almost perfect agreement in phase 2 (0.81),
and perfect agreement in phase 3 (1.0) (classification according to Landis and
Koch [15]). The extraction of statements showed a 76% agreement. The observed
agreement is a positive indicator for the validity of the selection process. A
third author as mediator to solve conflicts further strengthens this.

###  II-B Curation of Architectural Security Guidelines

TABLE I: Filtering criteria for statements in the analysed articles. _Concrete_ |  The statement clearly describes a (non-) desired system property or pattern.
---|---
_In Scope_ |  The statement refers to the architectural design or architectural components of AI-based systems.

We analyzed the selected articles and extracted statements that are relevant
for answering our formulated research questions. Specifically, we looked for
concrete descriptions of a desired or non-desired property of AI-based systems
that refers to their architectural components. Table I presents these
filtering criteria we applied to identify relevant statements. They were
adopted from a comparable study about architectural security rules for
microservice applications [16].

As for the selection of articles, two authors independently performed this
extraction of statements and a third author helped solve conflicts in a
discussion. The retained statements were then discussed with all authors to
create a comprehensive list of guidelines that represent all statements found
in the analyzed articles. In this discussion, we constructed guidelines out of
the found statements by merging similar ones and formulating them in a similar
style. As a final check, all three authors validated that the final list of
guidelines represents all statements extracted from the selected articles.

##  III Gray Literature Study with Negative Results

Figure 2: Methodology of gray literature study with negative results.

We had initially planned to curate architectural security guidelines via an
MLR [17]. However, when we conducted the gray literature study, it did not
yield any relevant resources.

TABLE II: Organizations considered in the gray literature study. Organization | Resources | Organization | Resources
---|---|---|---
| after phase 1 |  | after phase 1
BSA | 11 | MITRE | 10
BSI | 7 | MITRE ATLAS |
CERT-EU |  | NCSC | 2
CIS |  | NIST | 2
CISA |  | NSA |
CSA | 1 | OECD | 2
ENISA | 7 | OpenSSF |
ESI |  | OWASP |
ESCO |  | SANS Institute |
FIRST |  | SAFECode |
Total: 42

Figure 2 shows the methodology we followed for the gray literature study. It
is adapted from the one used by Tukaram et al. [16]. We looked for resources
published by large organizations that offer best-practice guides and other
resources for developers. We created a list of 17 such organizations via the
expert knowledge of six security researchers, three of which are authors and
the rest are colleagues of them. The list was extended by forward snowballing
via the Google Search engine. Table II shows the resulting list of 20
organizations. Two authors went through all resources published by each of the
organizations to select all those that are related to AI and of which the
title and description indicated that they could contain information about the
architectural design of AI-based systems. This resulted in the selection of 42
resources.

They then independently checked those resources in detail for adherence to the
formulated in- / exclusion criteria (as presented above in Section II). Upon
further inspection, both authors decided that no resource fit the inclusion
criteria. None of the found resources presents guidelines or any other
architectural information for AI-based systems.

The examined organizations are highly regarded by practitioners and often
serve as a source of the latest, high-quality information on how to implement
and use specific technological solutions. Considering this, the negative
outcome of this study is worrying, as it indicates a lack of available
guidance for developers working on AI-based systems. This can in turn lead to
architectural security issues of those systems.

##  IV Guidelines Curated from Literature (RQ1)

TABLE III: Primary Studies. ID | Title | Authors | Year
---|---|---|---
S1 | Responsible AI Pattern Catalogue: A Collection of Best Practices for AI Governance and Engineering [18] | Lu et al. | 2023
S2 | Characterizing Technical Debt and Antipatterns in AI-Based Systems: A Systematic Mapping Study [19] | Bogner et al. | 2021
S3 | A Survey of Privacy Risks and Mitigation Strategies in the Artificial Intelligence Life Cycle [20] | Shahriar et al. | 2023

The conducted SLR resulted in the selection of three articles that present
architectural guidelines for designing AI-based systems. They are presented as
studies S1 – S3 in Table III.

Study S1 [18] presents the findings of a multi-vocal literature review on
design patterns for AI-based systems that foster responsible AI. Many of the
presented patterns are implementation-oriented, but procedural and other
recommendations not relevant for us are also contained. Study S2 [19] lists
types of technical debt and antipatterns that apply to AI-based systems and
were identified via a systematic mapping study. Specific instances of the
proposed catalog of technical debt and antipatterns are only occasionally
presented, and the accompanying replication package also lacks details in some
cases. We thus also investigated the mentioned primary studies of S2 for more
details where needed. Study S3 [20] presents a survey on privacy risks of AI-
based systems along with possible mitigations. Due to its focus on privacy,
most presented risks are related to the collection and use of data.

Although we had not set out to conduct a tertiary study, the selection process
produced only secondary studies. We hypothesize that this happened because we
looked for papers presenting generalized results instead of findings of
specific case-studies. We deduce, that the literature on the matter seems to
be still in its infancy. A look at the primary studies used in S1 – S3
confirms this observation. The majority of them describe observations of
specific cases.

TABLE IV: Architectural security guidelines for AI-based systems (RQ1.1) and
the rationale given for their introduction (RQ1.2).
A filled box ($\blacksquare$) under “S1 S2 S3” indicates, that the guideline is mentioned in the corresponding source S1 – S3. ID |  Guideline |  S1 S2 S3 |  Rationale
---|---|---|---
G1 |  AI-mode switcher: An AI mode switcher can be used to let the human user control whether AI components’ outcomes are followed automatically or taken as suggestions and reviewed by the user. |  $\blacksquare\;\square\;\square$ |  Safety, security
G2 |  Multi-model decision maker: Employing a multi-model decision maker consisting of more than one different AI components can increase the system’s reliability and fault-tolerance. |  $\blacksquare\;\square\;\square$ |  Ethics, performance, reliability
G3 |  Redundant AI components: Deploying multiple identical AI components in parallel can ensure tolerance towards a malicious or otherwise disfunctioning AI component. |  $\blacksquare\;\square\;\square$ |  Ethics, reliability, security
G4 |  Ethical black box: AI components’ outcomes and related system information should be recorded in a black box. If rewards are used as incentive for ethical behaviour, they should be recorded as well. |  $\blacksquare\;\square\;\square$ |  Ethics, explainability, responsible AI
G5 |  Continuous monitoring: AI components’ outcomes should continuously be checked for their adherence to ethical requirements. |  $\blacksquare\;\square\;\square$ |  Ethics
G6 |  Monitoring AI components’ discrepancies: If multiple redundant AI components are deployed, their outcomes should be monitored to identify discrepancies. |  $\blacksquare\;\square\;\square$ |  Accountability, safety, security
G7 |  Adapting traditional design methods: Architectural design methods used for traditional systems (e.g., UML diagrams) can be adapted and used for AI-based systems as well and can model ethical requirements. |  $\blacksquare\;\square\;\square$ |  Ethics, Responsible AI
G8 |  Access via APIs: AI-based systems can be made available via APIs instead of allowing users to run them locally to keep control over their use. |  $\blacksquare\;\square\;\square$ |  Responsible AI, Security
G9 |  Bill of materials registry: A bill of materials registry should be integrated that keeps a machine-readable record of all used components and their properties. |  $\blacksquare\;\square\;\square$ |  Ethics, Responsible AI, Security
G10 |  Reusable components: Components should be implemented as reusable units with clearly defined boundaries and explicit interfaces. Complex dependencies and entanglement should be avoided. |  $\square\;\blacksquare\;\square$ |  Maintainability
G11 |  Compatible data types: Incompatible data types between AI and other components should be avoided. |  $\square\;\blacksquare\;\square$ |  N/A
G12 |  Single programming language: The use of multiple programming languages in the same system should be avoided where possible. |  $\square\;\blacksquare\;\square$ |  Maintainability, security
G13 |  No undeclared consumers: Undeclared consumers of AI components should be avoided and access control for the outcomes of the AI components should be enforced. |  $\square\;\blacksquare\;\square$ |  Security
G14 |  Performance monitoring: There should be a component that monitors the performance of the AI components concerning their prediction accuracy. |  $\square\;\blacksquare\;\square$ |  Maintainability
G15 |  Sufficient resources: Sufficient computing and memory resources have to be available for the AI components. |  $\square\;\blacksquare\;\blacksquare$ |  Performance
G16 |  Secure data storage: When data is collected for re-training, it has to be stored securely and according to applicable regulations such as the GDPR. This includes the use of encryption techniques, a firewall between data storage and network, and enforcement of access control. |  $\square\;\square\;\blacksquare$ |  Compliance, privacy, security

The analysis of the identified articles resulted in the formulation of 16
architectural security guidelines for AI-based systems. Table IV presents them
as G1 – G16. They are described briefly in the following. G1 suggests adding
an AI-mode switcher to the architecture that acts “like a kill switch” [18]
for the AI component(s). The switch changes the mode of the system from
automatically acting on outcomes of the AI component(s) to treating them as
suggestions that have to be reviewed by the user first. Deploying multiple
different (G2) or identical (G3) AI components in parallel can be advantageous
for the case that one of them acts maliciously or otherwise dysfunctional and
can increase the system’s reliability by employing a consensus mechanism
between them [21]. The outcomes of the AI component(s) and incentives given
for them should be recorded in a “black box” [22] as known from airplanes to
enable an analysis of what caused an undesired system behavior in the case
that this happens (G4). The outcomes should also be continuously checked
against ethical requirements to ensure they are still met even after re-
training the models (G5) [23], and they should be compared against each other
to identify discrepancies between the models’ outcomes (G6) [24]. G7 suggest
adapting existing tools and techniques for designing the architecture of
software systems to AI-based systems as well. Further, opening the access to
AI-based systems to users can be done via APIs instead of letting users deploy
them on their own machines (G8). This keeps the developers in control over the
system and its acceptable use. G9 suggests keeping a bill of materials
registry that records relevant information about all components that are part
of the AI-based system and the data used for training the AI component(s).
This allows traceability and transparency, especially when issues in the
systems’ behavior occur. G10 addresses the observation that the code of AI-
based systems tends to be poorly structured and not follow established coding
practices such as well-defined interfaces of components [25, 26]. G11 also
concerns the connection between AI component(s) and others, noting that
incompatible data types can often be an issue leading to a large amount of
glue code and should therefore be avoided [27]. According to G12, the use of
multiple programming languages in the development of an AI-based system should
be avoided where possible, because it makes testing, automated refactoring,
and deployment more difficult [28]. G13 states that access to the outcomes of
the AI component(s) should be secured by enforcing access control and
identifying all consumers [25]. Otherwise, control over potential misuses of
the outcomes can not reliably be kept. G14 states that a monitoring component
should be deployed to identify performance degradation in the prediction
accuracy of the AI component(s) [29]. G15 addresses the issue that AI-based
systems are often deployed with insufficient resources for the AI component to
run properly when moving from development to production [27]. When data is
collected by the deployed AI-based system for re-training purposes, it has to
be protected in accordance to applicable regulations and using traditional
security mechanisms (G16) [30, 31].

As visible in the column “prevalence” in Table IV, G15 is the only guideline
that was mentioned in more than one of the sources S1 – S3. A bigger overlap
between the sources would be desirable, as it would indicate their validity.
Most likely, this is due to us only identifying three sources for
architectural guidelines, which additionally approach the issue from different
motivations and are secondary studies. Therefore, we hope for more related
work in the future that would allow assessing overlaps between sources.

We summarize that, overall, research on actionable support for practitioners
working on the architecture of AI-based systems is ongoing and that various
guidelines can be found. On the other hand, the small number of identified
articles and rather small number of resulting guidelines shows the limited
extent of tangible guidance.

RQ 1.1: We identified 16 architectural security guidelines in the academic
literature, presented in Table IV. As described in Section III, no guidelines
were found in the gray literature we examined.

Table IV presents in the right-most column the rationales given as
justification for introducing each guideline. For most guidelines, it reflects
the general motivation of the corresponding source. For example, seven out of
nine guidelines found in S1 have “ethics” or “responsible AI” as one of the
rationales, i.e., the requirement that the AI-based systems behave in an
ethical and responsible way, as is expected by the paper’s title and goal.
Nevertheless, the rationales are diverse across all guidelines, with 11
distinct ones mentioned, covering different aspects of security, ethics, and
general system qualities.

Interestingly, just over half of the guidelines (7) mention more than one
individual rationales as justification for their introduction. This speaks for
the importance of the guidelines, as they seem to support cross-cutting
improvement of different quality aspects of the systems. For some of those
guidelines only mentioning one rationale, they are likely to also contribute
to further qualities of the AI-based systems. For example, the paper proposing
G10 mentions maintainability as rationale, however, the systems’ security
would likely also benefit from clearly defined components as this helps
developers gain and maintain an overview of the architecture and prevent
security issues.

RQ 1.2: Table IV presents the rationales given for introducing each of the
curated guidelines. A total of 11 individual rationales are mentioned. They
show various aspects of security, ethics, and general system qualities, with
“ethics” and “security” being the most prevalent ones.

##  V Mapping to Typical Components of AI-based Systems (RQ2)

We mapped the guidelines identified via our SLR to typical components of AI-
based systems to examine the coverage of the architecture, i.e., those parts
for which guidelines could be found in the literature. As the basis for the
mapping, we took an example architecture proposed by Kästner [9] and
generalized those components that were use-case specific. It is taken from a
popular course on developing AI-based systems and the author is a known expert
in the field. We are aware that other representations of AI-based systems
exist and could be used as the basis for the mapping. For example, Sculley et
al. [25] presented a generic architecture of AI-based systems that includes
the production pipeline and detailed data science pipeline used to create the
AI components. In this work, however, we focus on the architecture of the
final product and hence selected the architecture by Kästner [9] as the basis
for our mapping. Specifically, G7 is the only identified guideline that is
clearly and only related to the development process.

We mapped the guidelines in Table IV to the resulting generic architecture by
identifying which component of the architecture each guideline applies to. The
mapping was performed in a discussion with two authors. No ambiguities
occurred, and the connections between guidelines and components are rather
straightforward.

Figure 3: Mapping of architectural security guidelines to typical components
of AI-based systems, adapted from Kästner [9].

Figure 3 shows the generic architecture and the mapping of the guidelines. The
guidelines are distributed well across the components, and we see a high
coverage of the typical components of AI-based systems. The “User Interface”
and “Business Logic” are the only two that do not have any guidelines directly
associated to them, but both have a guideline concerning their interaction
with the AI component(s). Most components only have a single guideline
associated to them.

The lack of guidelines for the “Business Logic” is surprising. We would have
expected to find recommendations about how to securely handle AI components’
outcomes and how the systems’ core functionality should address the non-
determinism introduced by it. The comparatively large number of guidelines
related to monitoring and logging is based on the prevalence of ethical
considerations as rationale for the guidelines. It also shows a tendency to
supervise AI components well to address possibly malicious ones and changing
behavior based on re-training.

The high coverage of the typical components of AI-based systems is generally
seen as a positive sign for the state of the art in research on the topic.
Most components contained in AI-based systems are considered by at least one
guideline. We note that different components for the generic architectures
could be proposed by others. We do not claim completeness or generality for
either the used architecture by Kästner [9] or our derived one. However, we
believe it to be generic enough to allow the presented general observations
and discussion.

RQ 2: Mapping the guidelines to the typical components of AI-based systems
showed a high coverage of the components. “User Interface” and “Business
Logic” are the only two components without a guideline directly associated to
them. Figure 3 shows the complete mapping.

##  VI Threats to Validity

All manual steps of the SLR and the gray literature review, the curation of
the guidelines, and their mapping to the typical components of AI-based
systems could have been subject to selection bias, search bias, extraction
errors, and synthesis bias. This can affect the reliability and
generalizability of the presented results. We addressed this with robust and
established methods by performing all steps with two authors independently,
solving conflicts with a third author, formulating reproducible in- /
exclusion and filtering criteria, measuring agreement with Cohen’s Kappa, and
publishing a replication package [13].

The small number of found articles, which in addition are all secondary
studies, suggests that the exclusion criteria might have been too restrictive.
However, all criteria were necessary to exclude a large amount of irrelevant
articles and all are well motivated and cater to the research questions. We
believe a lack of research on the topic to be the reason for the small number
of selected articles.

The architecture used for the mapping is not based on a sound study but on
experience of the author of the initial architecture. No other architecture
was found in the related literature that would lend itself to such a mapping,
and we do not claim generality.

##  VII Related Work

Many experience reports and case-studies have been published in the related
literature that present specific challenges and possible solutions for the
architectural design of AI-based systems. They are covered by the articles
that we identified with our SLR and are thus not presented additionally here.

Some authors also presented studies that summarize such specific work into
more general sets of recommendations and guidelines, focusing on different
aspects of the development of AI-based systems, such as collaboration
challenges between practitioners [32], architectural patterns for federated
learning systems [33], specific technical debt [25], or general challenges of
engineering such systems [34]. The studies identified with our SLR also fit
into this category (presented below).

Tukaram et al. [16] curated architectural security rules for microservice
applications. They analyzed resources published by organizations as we aimed
to do with our gray literature study that yielded no results (presented below
in Section III). Except for the different domain, their paper and results are
similar to ours, and we adapted parts of their methodology.

To the best of our knowledge, no work has been presented in the academic
literature that aimed to curate architectural security guidelines for AI-based
systems.

##  VIII Research Outlook

  1. 1.

More research efforts should be applied to the architectural security of AI-
based systems, as it seems to trail behind the work on other security aspects.
In particular, we are astonished that the large, emerging literature on
attacks to AI/ML has not translated yet to advice related to possible
countermeasures.

  2. 2.

Architectural security guidelines for AI-based systems would greatly benefit
from the expertise of the practitioners at the forefront of their development.
In this respect, a large-scale survey could be a useful instrument.

  3. 3.

Attention should be given to the problem of compliance and certification with
respect to these (and future) design guidelines. Methodologies and tools
should be created that allow analyses of these aspects.

## Acknowledgement

This work was supported by EU-funded project Sec4AI4Sec (grant no. 101120393).

## References

  * [1] S. Amershi, A. Begel, C. Bird, R. DeLine, H. Gall, E. Kamar, N. Nagappan, B. Nushi, and T. Zimmermann, “Software engineering for machine learning: A case study,” in 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), pp. 291–300, 2019\.
  * [2] L. Deng, “Artificial intelligence in the rising wave of deep learning: The historical path and future outlook [perspectives],” IEEE Signal Processing Magazine, vol. 35, no. 1, pp. 180–177, 2018.
  * [3] J. Bosch, I. Crnkovic, and H. H. Olsson, “Engineering ai systems: A research agenda,” 2020.
  * [4] S. Martínez-Fernández, J. Bogner, X. Franch, M. Oriol, J. Siebert, A. Trendowicz, A. M. Vollmer, and S. Wagner, “Software engineering for ai-based systems: A survey,” ACM Trans. Softw. Eng. Methodol., vol. 31, apr 2022.
  * [5] Y. Hu, W. Kuang, Z. Qin, K. Li, J. Zhang, Y. Gao, W. Li, and K. Li, “Artificial intelligence security: Threats and countermeasures,” ACM Comput. Surv., vol. 55, nov 2021.
  * [6] Y. Acar, C. Stransky, D. Wermke, C. Weir, M. L. Mazurek, and S. Fahl, “Developers need support, too: A survey of security advice for software developers,” in 2017 IEEE Cybersecurity Development (SecDev), pp. 22–26, 2017.
  * [7] H. Muccini and K. Vaidhyanathan, “Software architecture for ml-based systems: What exists and what lies ahead,” in 2021 IEEE/ACM 1st Workshop on AI Engineering - Software Engineering for AI (WAIN), (Los Alamitos, CA, USA), pp. 121–128, IEEE Computer Society, may 2021.
  * [8] G. A. Lewis, I. Ozkaya, and X. Xu, “Software architecture challenges for ml systems,” in 2021 IEEE International Conference on Software Maintenance and Evolution (ICSME), pp. 634–638, 2021.
  * [9] C. Kästner, “Machine Learning in Production: from Models to Products,” 2022\.
  * [10] B. Kitchenham, “Procedures for performing systematic reviews,” Keele, UK, Keele Univ., vol. 33, 08 2004.
  * [11] B. Kitchenham and S. Charters, “Guidelines for performing systematic literature reviews in software engineering,” vol. 2, 01 2007.
  * [12] P. Ralph, N. b. Ali, S. Baltes, D. Bianculli, J. Diaz, Y. Dittrich, N. Ernst, M. Felderer, R. Feldt, A. Filieri, et al., “Empirical standards for software engineering research,” arXiv preprint arXiv:2010.03525, 2020.
  * [13] S. Schneider, A. Saha, E. Mezzi, K. Tuma, and R. Scandariato, “Replication package for ’Architectural Security Guidelines for AI-based Systems’,” May 2024\.
  * [14] S. M. Vieira, U. Kaymak, and J. M. C. Sousa, “Cohen’s kappa coefficient as a performance measure for feature selection,” in International Conference on Fuzzy Systems, pp. 1–8, 2010.
  * [15] J. R. Landis and G. G. Koch, “The measurement of observer agreement for categorical data,” Biometrics, vol. 33, no. 1, pp. 159–174, 1977.
  * [16] A. Bambhore Tukaram, S. Schneider, N. E. Díaz Ferreyra, G. Simhandl, U. Zdun, and R. Scandariato, “Towards a security benchmark for the architectural design of microservice applications,” in Proceedings of the 17th International Conference on Availability, Reliability and Security, ARES ’22, (New York, NY, USA), Association for Computing Machinery, 2022.
  * [17] V. Garousi, M. Felderer, and M. V. Mäntylä, “Guidelines for including grey literature and conducting multivocal literature reviews in software engineering,” Information and Software Technology, vol. 106, pp. 101–121, 2019.
  * [18] Q. Lu, L. Zhu, X. Xu, J. Whittle, D. Zowghi, and A. Jacquet, “Responsible ai pattern catalogue: A collection of best practices for ai governance and engineering,” ACM Comput. Surv., vol. 56, apr 2024.
  * [19] J. Bogner, R. Verdecchia, and I. Gerostathopoulos, “Characterizing technical debt and antipatterns in ai-based systems: A systematic mapping study,” in 2021 IEEE/ACM International Conference on Technical Debt (TechDebt), pp. 64–73, IEEE, May 2021.
  * [20] S. Shahriar, S. Allana, S. M. Hazratifard, and R. Dara, “A survey of privacy risks and mitigation strategies in the artificial intelligence life cycle,” IEEE Access, vol. 11, pp. 61829–61854, 2023.
  * [21] M. Nafreen, S. Bhattacharya, and L. Fiondella, “Architecture-based software reliability incorporating fault tolerant machine learning,” in 2020 Annual Reliability and Maintainability Symposium (RAMS), pp. 1–6, 2020.
  * [22] A. F. Winfield and M. Jirotka, “The case for an ethical black box,” In: Gao Y., Fallah S., Jin Y., Lekakou C. (eds) Towards Autonomous Robotic Systems. TAROS 2017. Lecture Notes in Computer Science, vol 10454. Springer, Cham, 2018.
  * [23] M. Staples, L. Zhu, and J. Grundy, “Continuous validation for data analytics systems,” in 2016 IEEE/ACM 38th International Conference on Software Engineering Companion (ICSE-C), pp. 769–772, 2016.
  * [24] B. S. Miguel, A. Naseer, and H. Inakoshi, “Putting accountability of ai systems into practice,” in Proceedings of the Twenty-Ninth International Joint Conference on Artificial Intelligence, IJCAI’20, 2021.
  * [25] D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V. Chaudhary, M. Young, J.-F. Crespo, and D. Dennison, “Hidden technical debt in machine learning systems,” in Advances in Neural Information Processing Systems (C. Cortes, N. Lawrence, D. Lee, M. Sugiyama, and R. Garnett, eds.), vol. 28, Curran Associates, Inc., 2015.
  * [26] S. Amershi, A. Begel, C. Bird, R. DeLine, H. Gall, E. Kamar, N. Nagappan, B. Nushi, and T. Zimmermann, “Software engineering for machine learning: A case study,” in 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), pp. 291–300, 2019\.
  * [27] G. A. Lewis, S. Bellomo, and A. Galyardt, “Component mismatches are a critical bottleneck to fielding ai-enabled systems in the public sector,” in AAAI FSS-19: Artificial Intelligence in Government and Public Sector, 2019.
  * [28] S. Schelter, F. Biessmann, T. Januschowski, D. Salinas, S. Seufert, and G. Szarvas, “On challenges in machine learning model management,” IEEE Data Engineering Bulletin, 2015.
  * [29] A. Agarwal, S. Bird, M. Cozowicz, L. Hoang, J. Langford, S. Lee, J. Li, D. Melamed, G. Oshri, O. Ribas, et al., “Making contextual decisions with low technical debt,” arXiv preprint arXiv:1606.03966, 2016.
  * [30] P. Jain, M. Gyanchandani, and N. Khare, “Big data privacy: a technological perspective and review,” Journal of Big Data, vol. 3, 11 2016.
  * [31] E. Kasneci, K. Sessler, S. Küchemann, M. Bannert, D. Dementieva, F. Fischer, U. Gasser, G. Groh, S. Günnemann, E. Hüllermeier, S. Krusche, G. Kutyniok, T. Michaeli, C. Nerdel, J. Pfeffer, O. Poquet, M. Sailer, A. Schmidt, T. Seidel, M. Stadler, J. Weller, J. Kuhn, and G. Kasneci, “Chatgpt for good? on opportunities and challenges of large language models for education,” Learning and Individual Differences, vol. 103, p. 102274, 2023\.
  * [32] N. Nahar, S. Zhou, G. Lewis, and C. Kästner, “Collaboration challenges in building ml-enabled systems: communication, documentation, engineering, and process,” in Proceedings of the 44th International Conference on Software Engineering, ICSE ’22, (New York, NY, USA), p. 413–425, Association for Computing Machinery, 2022.
  * [33] S. K. Lo, Q. Lu, L. Zhu, H.-Y. Paik, X. Xu, and C. Wang, “Architectural patterns for the design of federated learning systems,” Journal of Systems and Software, vol. 191, p. 111357, 2022.
  * [34] L. E. Lwakatare, A. Raj, J. Bosch, H. H. Olsson, and I. Crnkovic, “A taxonomy of software engineering challenges for machine learning systems: An empirical investigation,” in Agile Processes in Software Engineering and Extreme Programming (P. Kruchten, S. Fraser, and F. Coallier, eds.), (Cham), pp. 227–243, Springer International Publishing, 2019.


# Search for Correlations between HiRes Stereo Events and Active Galactic
Nuclei

R. U. Abbasi  T. Abu-Zayyad  M. Allen  J. F. Amman  G. Archbold  K. Belov  J.
W. Belz  S. Y. BenZvi  D. R. Bergman  S. A. Blake  J. H. Boyer  O. A. Brusova
G. W. Burt  C. Cannon  Z. Cao  W. Deng  Y. Fedorova  J. Findlay  C. B. Finley
R. C. Gray  W. F. Hanlon  C. M. Hoffman  M. H. Holzscheiter  G. Hughes  P.
Hüntemeyer  D. Ivanov  B. F Jones  C. C. H. Jui  K. Kim  M. A. Kirn  B. C.
Knapp  E. C. Loh  M. M. Maestas  N. Manago  E. J. Mannel  L. J. Marek  K.
Martens  J. N. Matthews  S. A. Moore  A. O’Neill  C. A. Painter  L. Perera  K.
Reil  R. Riehle  M. D. Roberts  D. Rodriguez  N. Sasaki  S. R. Schnetzer  L.
M. Scott Corresponding author<EMAIL_ADDRESS>M. Seman  G. Sinnis
J. D. Smith  R. Snow  P. Sokolsky  C. Song  R. W. Springer  B. T. Stokes  S.
R. Stratton  J. R. Thomas  S. B. Thomas  G. B. Thomson  D. Tupa  L. R. Wiencke
A. Zech  X. Zhang  University of Utah, Department of Physics, Salt Lake City,
UT 84112, USA  Los Alamos National Laboratory, Los Alamos, NM 87545, USA
Montana State University, Department of Physics, Bozeman, MT 59812, USA
Columbia University, Department of Physics and Nevis Laboratory, New York, NY
10027, USA  Rutgers — the State University of New Jersey, Piscataway, NJ
08854, USA  University of Tokyo, Institute for Cosmic Ray Research, Kashiwa
City, Chiba 277-8582, Japan  University of New Mexico, Department of Physics
and Astronomy, Albuquerque, NM 87131, USA

###### Abstract

We have searched for correlations between the pointing directions of ultrahigh
energy cosmic rays observed by the High Resolution Fly’s Eye experiment and
Active Galactic Nuclei (AGN) visible from its northern hemisphere location. No
correlations, other than random correlations, have been found. We report our
results using search parameters prescribed by the Pierre Auger collaboration.
Using these parameters, the Auger collaboration concludes that a positive
correlation exists for sources visible to their southern hemisphere location.
We also describe results using two methods for determining the chance
probability of correlations: one in which a hypothesis is formed from scanning
one half of the data and tested on the second half, and another which involves
a scan over the entire data set. The most significant correlation found
occurred with a chance probability of 24%.

###### keywords:

Active Galactic Nuclei , ultrahigh energy cosmic rays , anisotropy

, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
, , , , , , , , , , , , , , , , , , , , , , , ,
(The High Resolution Fly’s Eye Collaboration)

##  1 Introduction

The search for the sources of the highest energy cosmic rays is an important
topic in physics today. The energies of these cosmic rays exceed 100 EeV and
the acceleration mechanisms of the astrophysical objects responsible for these
events remain unknown. Anisotropy search methods such as those used in X- or
$\gamma$-ray astronomy are difficult to use due to deflections in the
trajectories of these charged cosmic rays from Galactic and extragalactic
magnetic fields. For a galactic magnetic field strength of $\sim 3\mu$G and
coherence length of $\sim 1$ kpc, a 40 EeV cosmic ray should be deflected by
two to three degrees over a distance of only a few kpc [1].

There are several reports on anisotropy by previous experiments. An excess of
events near the direction of the Galactic center has been reported by the
SUGAR and AGASA experiments [2, 3]. The Pierre Auger collaboration, however,
has recently reported that they have not seen any excess at that location [4].
In addition, the Auger collaboration reported no significant excesses in any
part of the southern hemisphere sky [5]. Two reports of anisotropy have been
found in the northern hemisphere sky. A dip in the intensity of cosmic-ray
events near the direction of the Galactic anticenter has been reported by both
the AGASA and High Resolution Fly’s Eye (HiRes) experiments, but the
significance is too low to claim an observation [6]. Additionally the AGASA
“triplet” is correlated with a HiRes high-energy event [7]. These reports of
anisotropy in the northern sky await confirmation or rejection by the
Telescope Array experiment [8].

Another method for searching for anisotropy is to search for correlations in
pointing directions of cosmic rays with known astrophysical objects that might
be sources. In these cases, a small event sample that shows no excess over the
expected background can, nevertheless, exhibit correlations with _a priori_
candidate sources, adding up to a statistically significant signal. Past
searches have found correlations with BL Lacertae objects; BL Lacs are a class
of AGN with a jet pointing toward the Earth, and are plausible candidates for
cosmic-ray sources. Correlations have been found with data from the AGASA,
HiRes and Yakutsk experiments, all in the northern hemisphere [9]. The Auger
collaboration has searched for correlations with BL Lac objects in the
southern hemisphere but has found nothing significant [10]. Again the northern
hemisphere correlations await confirmation by the Telescope Array experiment.

There have been speculations that Active Galactic Nuclei (AGN) may contain
acceleration regions of the appropriate size and magnetic field strength to
accelerate nuclei to the highest energies [11, 12]. One should therefore
expect the brightest and closest AGN to produce the highest-energy cosmic ray
events at Earth. These events would also have suffered the smallest
deflections due to the intervening magnetic fields and would point back, most
directly, to these AGN. The large number of identified AGN make them
interesting candidates for studying possible correlations with ultrahigh
energy cosmic rays. Three ideal parameters for determining correlations
between cosmic rays and AGN are the maximum difference in angle between the
cosmic-ray pointing direction and the AGN $\theta_{max}$, the minimum cosmic-
ray energy $E_{min}$, and the maximum AGN redshift $z_{max}$.

The Pierre Auger Collaboration have reported a search of two independent sets
of their data for correlations with cosmic rays with AGN. They scanned their
first data set and found that the most significant correlation occurs for
cosmic rays with parameters ($\theta_{max}$, $E_{min}$, $z_{max}$) =
($3.1^{\circ}$, 56 EeV, 0.018). With these selection criteria, they find 12
pairings with AGN from 15 events in the first data set. In the second data
set, they find 8 pairings from 13 events and a corresponding chance
probability of 0.0017 [13, 14].

The HiRes experiment collected data from 1997 to 2006, operating two
fluorescence detectors located atop desert mountains separated by 12.6 km in
west-central Utah. The HiRes data have been analyzed monocularly, using the
data from one detector at a time [15], and stereoscopically, using the data
from both detectors simultaneously [16]. The angular resolution is about
$0.8^{\circ}$ in stereo mode. The energy scales of the HiRes monocular and
stereoscopic reconstructions agree. Only stereo data were used in this
analysis. The stereo data, covering an energy range from $10^{17.4}$ to
$10^{20.1}$ eV, consist of 6636 events.

The pointing directions of the stereo data extend from zenith to about
$-32^{\circ}$ in declination (celestial coordinates). The corresponding
exposure of is dependent on right ascension due to seasonal variations in the
duty cycle of the detector. The boundaries of regions of equal exposure are
best described by

$\displaystyle\delta=\left\\{\begin{array}[]{ll}A+B\sin\left[\frac{9}{10}\
\alpha\right]&\mbox{ (if $\alpha\leq 200^{\circ}$) }\\\
A+C\sin\left[\frac{9}{8}\ (\alpha-200^{\circ})\right]&\mbox{ (if
$\alpha>200^{\circ}$) }\end{array}\right.$ (3)

where $\delta$ and $\alpha$ are celestial declination and right ascension
measured in degrees and $A$, $B$ and $C$ are fit parameters. Table 1 gives
values of $A$, $B$ and $C$ for plotting the boundaries of the 10 bins of equal
exposure shown in Figures 3 and 4.

Table 1: Parameters for the functions in Equation 3 that give the coordinates (in celestial right ascension and declination) of the lower boundaries of the 10 bins of equal exposure for the HiRes detector shown as the 10 lightest shaded regions in Figures 3 and 4. Bin | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10
---|---|---|---|---|---|---|---|---|---|---
A | 67.9 | 55.3 | 45.5 | 36.9 | 28.8 | 20.7 | 12.3 | 3.3 | -12.1 | -32.0
B | 2.0 | 3.0 | 3.8 | 4.7 | 5.5 | 6.6 | 7.9 | 9.4 | 17.6 | 0.0
C | -3.1 | -4.4 | -5.6 | -7.0 | -8.8 | -11.5 | -15.7 | -26.2 | -19.1 | 0.0

Figure 1 shows the monocular spectra for the two HiRes sites [15] and that of
the Pierre Auger Observatory [17]. At the highest energies where Auger
observes an anisotropy signal, the energy scales of HiRes and Auger differ by
about 10%. To account for this difference, the energy scale of the HiRes
stereo data set used in this analysis has been decreased by 10% to agree with
the Auger energy scale. All energies quoted for the HiRes data from this point
on will include this 10% shift. There are 13 events with energies greater than
56 EeV in the full HiRes stereo data set, the same number as in the Auger test
data set.

Figure 1:  Energy spectrum [$E^{3}J$] for HiRes-1 and HiRes-2 monocular data
[15] and for the surface detector data from the Pierre Auger Observatory [17].

##  2 The Véron-Cetty and Véron catalog

In this paper, we report on searches for correlations between the pointing
directions of ultrahigh energy cosmic rays observed stereoscopically by the
HiRes experiment and AGN from the Véron-Cetty and Véron (VCV) catalog, 12th
edition [18]. The VCV catalog includes $\sim 22000$ AGN, $\sim 550$ BL-Lacs
and $\sim 85000$ quasars compiled from observations made by other scientists,
and does not evenly cover the sky. Not only does the Galaxy and its associated
dust cover large parts of the sky, particularly in the southern hemisphere,
making the identification of AGN extremely difficult in those areas, but some
of the sky surveys included in the catalog have covered only small bands of
the sky. This makes the total density of AGN in the VCV catalog very uneven
across the sky in a way that is neither totally random nor systematic. The
locations of a closer subset of sources, with redshift $z<0.1$, are more
evenly distributed.

One property of the search method in ($\theta_{max}$, $E_{min}$, $z_{max}$) is
that the large size of the catalog and the size of the correlation angle
circles determine that one can scan over only a narrow range of $\theta_{max}$
and $z_{max}$. To illustrate this using simulated events with isotropically
distributed pointing directions, Figure 2 shows that the number of random
pairings with AGN is determined by the choice of $\theta_{max}$ and $z_{max}$.
As $\theta_{max}$ and $z_{max}$ are increased, the number of random pairings
increases, rapidly overcoming any real correlations between cosmic rays and
AGN.

Figure 2:  The average fraction of correlated events found in 5000 simulated
sets of isotropic events with identical statistics to the HiRes data for
$E>56$ EeV as a function of $\theta_{max}$ and $z_{max}$. The fraction of
correlated pairs of simulated events with AGN is 0.02 at ($1.0^{\circ}$,
0.010); 96% of events are correlated at ($10.0^{\circ}$, 0.100).

##  3 Method

We perform three searches for correlations between cosmic rays and AGN. In the
first search we look for correlations in the HiRes stereo data using the
($\theta_{max}$, $E_{min}$, $z_{max}$) parameters prescribed by the Auger
collaboration [13]. In the second, we divide our stereo data into two equal
parts in a random manner, determine the optimum search parameters in the first
half of the data by scanning in a three-dimensional grid in ($\theta_{max}$,
$E_{min}$, $z_{max}$), and then examine the second half of the data using
these “optimum” parameters. By choosing the best parameters from the first
half of the data and using them to form a hypothesis to be tested using a
statistically independent sample, no statistical penalties are incurred in the
application to the second half of the data. In the third and last search, we
analyzed the complete data set using the statistical prescription described by
Finley and Westerhoff [19] (see also Tinyakov and Tkachev [20]) to arrive at a
chance probability that includes the statistical penalty from scanning over
the entire data set. Finally, in addition to searching for correlations with
AGN, we analyzed the degree of auto-correlation in the stereo data over all
possible angles and values of $E_{min}$.

To arrive at the appropriate chance probabilities for the numbers of
correlations seen in each method, we generated 5001 random samples of events
using the hour angle - declination method [21, 6]. In this method the hour
angle and declination of one event and the sidereal time of another are
randomly paired to generate a sky plot with the same number of events as the
data. Such a sample reproduces the overall observed distribution of events
very well.

###  3.1 Search for Correlations using the Auger criteria

The Auger collaboration has reported the results of searches in
($\theta_{max}$, $E_{min}$, $z_{max}$) over two independent data sets. In a
scan over the first data set, 12 of the 15 events with $E_{min}~{}=~{}56.0$
EeV were found to lie within $\theta_{max}~{}=~{}3.1^{\circ}$ of AGN with
$z_{max}~{}=~{}0.018$ with 3.2 chance pairings expected. Using the parameters
($3.1^{\circ}$, 56.0 EeV, 0.018), 8 of 13 events in an independent test data
set were found to be paired with AGN with 2.7 chance pairings expected. The
chance probability for this occurrence was found to be 0.0017 [13, 14].

A scan of the entire HiRes data set at ($3.1^{\circ}$, 56.0 EeV, 0.018) found
2 AGN pairings for a total of 13 events. Figure 3 shows the locations of the 2
correlated events and the 11 uncorrelated events. We looked for correlations
in the 5000 simulated data sets at ($3.1^{\circ}$, 56.0 EeV, 0.018) and found
the average number of correlated pairs to be 3.2. In addition, 4121 sets had 2
or more correlated events for a chance probability of 82%. We thus find no
evidence for correlations of cosmic-ray events with AGN in our field of view
at ($3.1^{\circ}$, 56.0 EeV, 0.018). The HiRes data are therefore consistent
with random correlations.

Figure 3:  Sky map in Galactic coordinates. The black dots are the locations
of the 457 AGN and 14 QSOs with redshift $z<0.018$. The green circle and
triangle mark the locations of Centaurus A and M87, respectively. The red
circles (with radii of $3.1^{\circ}$) mark the 2 correlated events. The blue
squares mark the locations of the 11 uncorrelated events. Of the eleven blue
shaded regions, the 10 lightest shades delineate regions of constant exposure
in HiRes as given in Table 1. The darkest shade indicates the region with no
exposure.

###  3.2 Search in two independent data sets

Next, we randomly divide the HiRes stereo data into two equal sets, first
examining only one half and setting the other aside. We scan the first half
simultaneously in $\theta_{max}$ from 0.1 to $4.0^{\circ}$ in bins of
$0.1^{\circ}$, in $E_{min}$ from $10^{19.05}$ to $10^{19.80}$ eV in bins of
0.05 decade, and with an AGN $z_{max}$ from 0.010 to 0.030 in bins of 0.001.
For each grid point in the scan, the total number of cosmic rays correlated
with at least one AGN is accumulated. We then conduct the same scan in each of
5000 simulated sets with identical statistics to the first half, adding up the
total number of correlations in each set for each grid point. At each point,
the number of correlated events in each of the 5000 simulated sets is compared
with the result in the first half of the data. The criteria for the most
significant correlation were found to be ($1.7^{\circ}$, 15.8 EeV, 0.020) with
20 correlated events from a total of 97. Only 25 of 5000 simulated sets had 20
or more correlations.

Using these criteria as our hypothesis, we then examine the second half of the
data at ($1.7^{\circ}$, 15.8 EeV, 0.020) and find 14 correlated pairs from 101
events. In a set of 5000 simulated events with identical statistics to the
second half, 741 sets contained 14 or more correlated events for a chance
probability of 15%. For comparison, the point with the most significant
correlation in the second half occurs at ($2.0^{\circ}$, 20.0 EeV, 0.016) with
14 correlated events of a total 69 and a chance probability of 1.5%. These
results are again consistent with random correlations.

###  3.3  Scanning the entire data set

We follow the prescription of Finley and Westerhoff [19] for determining the
most significant correlation in the entire data set while also calculating an
appropriate statistical penalty for scanning over the entire data set. We scan
the data simultaneously in $\theta_{max}$, $E_{min}$ and $z_{max}$ counting
the number of correlated events, $n_{corr}$ at each point. This process is
repeated for each of the 5001 simulated sets with $P_{data}$, the probability
for observing $n_{corr}$ or more correlations at ($\theta_{max}$, $E_{min}$,
$z_{max}$) calculated from

$P_{data}(\theta_{max},z_{max},E_{min})=\sum_{n=n_{corr}}^{\infty}P_{mc}(\theta_{max},z_{max},E_{min},n)$
(4)

where $P_{mc}(\theta_{max},z_{max},E_{min},n)$ is the fraction of the first
5000 simulated sets with exactly $n$ events at ($\theta_{max}$, $E_{min}$,
$z_{max}$). The value of $P_{min}$ is then taken to be the values of
($\theta_{c}$, $E_{c}$, $z_{c}$) which minimize $P_{data}$. This is found to
occur at the critical values ($2.0^{\circ}$, 15.8 EeV, 0.016) where there are
36 correlated events out of 198 in the data and 9 of 5000 simulated sets with
36 or more correlated events, for a chance probability of 0.18%.

To find the true significance of this signal, we apply the same process to
each of the first 5000 simulated sets, finding the value
$P_{min}^{i}~{}=~{}P^{i}(\theta_{c}^{i},~{}E_{c}^{i},z_{c}^{i})$ by comparing
$n_{corr}^{i}$ with $n_{corr}$ for the other 5000 sets. We then count the
number of simulated sets $n_{mc}^{*}$ for which $P_{min}^{i}\leq P_{min}$. The
chance probability is then found as

$P_{chance}=\frac{n_{mc}^{*}}{5000}.$ (5)

In this, our most robust method, there were 1210 simulated sets with
$P_{min}^{i}$ values of 0.0018 or less for a chance probability,
$P_{chance}=24$%. Figure 4 shows a sky map of the most significant correlation
in the HiRes data. From this final analysis, we draw the same conclusion:
HiRes data are consistent with random correlations with AGN.

Figure 4:  Sky map in Galactic coordinates. The black dots are the locations
of the 389 AGN and 14 QSOs with redshift $z<0.016$. The green circle and
triangle mark the locations of Centaurus A and M87, respectively. The red
circles (with radii of $2.0^{\circ}$) mark the 36 correlated events at
($2.0^{\circ}$, 15.8 EeV, 0.016). The blue squares mark the locations of the
162 uncorrelated events. Of the eleven blue shaded regions, the 10 lightest
shades delineate regions of constant exposure in HiRes as given in Table 1.
The darkest shade indicates the region with no exposure.

##  4 Auto-correlation analysis

In addition to searching for correlations with AGN, studies of auto-
correlation can be useful for searching for anisotropy in the data. We have
analyzed the degree of auto-correlation in the data over all possible angles
and made comparisons with the average number of pairs of events for 2000
isotropic simulated data sets. We find no evidence of auto-correlation for any
values of $E_{min}$. Figure 5 shows a comparison of the normalized number of
pairs of events with energies above 56 EeV in the stereo data to the average
normalized number of pairs for 2000 isotropic simulated data sets. The
1$\sigma$ uncertainty is found by ordering the simulated sets by their maximum
deviation from the average and plotting only the first 68% of those simulated
sets.

As a further check, we scan the data in $\theta_{max}$ and $E_{min}$ and
determine a statistical penalty using the same method presented in Section
3.3. We scan the data in $\theta_{max}$ from $0.5^{\circ}$ to $30.0^{\circ}$
in bins of $0.5^{\circ}$ and in $E_{min}$ from $10^{19.05}$ to $10^{19.80}$ eV
in bins of 0.05 decade. The critical values which minimize $P_{data}$ are
found to occur at ($2.0^{\circ}$, 44.7 EeV) where there is one pair of events
out of a possible 406 in the data and 227 of 1000 simulated sets with one or
more pairs for a chance probability of 23%. Applying the same process to the
1000 simulated sets, we find 971 sets for which the critical point occurs with
a chance probability less than 23%. The probability of measuring the observed
degree of correlation in an isotropic data set is 97%.

Figure 5:  Normalized number of pairs as a function of $\theta_{max}$. The 13
events above 56 EeV in the HiRes data are shown in closed circles. The open
circles are the average of 2000 simulated sets. The gray shaded region
represents the 1$\sigma$ uncertainty in the distribution of simulated sets.

##  5 Conclusions

We have searched for correlations between the pointing directions of HiRes
stereo events with AGN from the the Véron-Cetty Véron catalog using three
different methods. As search parameters for our analysis, we used the maximum
difference in angle between the cosmic-ray pointing direction and an AGN
$\theta_{max}$, the minimum cosmic-ray energy $E_{min}$, and the maximum AGN
redshift $z_{max}$.

Our first analysis, using the criteria prescribed by the Pierre Auger
Observatory for their most significant correlation, ($3.1^{\circ}$, 56.0 EeV,
0.018), finds 2 correlated of 13 total events with an expectation of 3.2
chance correlations. The corresponding chance probability was found to be 82%.

In our second search the total HiRes stereo data were then divided into two
equal but random parts and we performed a scan in $\theta_{max}$, $E_{min}$
and $z_{max}$ over one half of the data to determine which parameters
optimized the correlation signal. We then examined the other half of the data
using these search parameters and found a smaller signal with a chance
probability of 15%.

Finally, we examined the entire HiRes stereo data using a more robust method
to calculate the chance probability with appropriate statistical penalties.
The most significant correlation was found to occur at ($2.0^{\circ}$, 15.8
EeV, 0.016) with 36 correlated of 198 total events. This corresponds to a
chance probability of 24%.

We conclude that there are no significant correlations between the HiRes
stereo data and the AGN in the Véron-Cetty Véron catalog. We also examined the
degree of auto-correlation at all angles and energies. The probability that
the data are consistent with isotropy is 97%.

## Acknowledgments

This work was supported by US NSF grants PHY-9100221, PHY-9321949,
PHY-9322298, PHY-9904048, PHY-9974537, PHY-0073057, PHY-0098826, PHY-0140688,
PHY-0245428, PHY-0305516, PHY-0307098, PHY-0649681, and PHY-0703893, and by
the DOE grant FG03-92ER40732. We gratefully acknowledge the contributions from
the technical staffs of our home institutions. The cooperation of Colonels E.
Fischer, G. Harter and G. Olsen, the US Army, and the Dugway Proving Ground
staff is greatly appreciated.

## References

  * [1] K. Dolag, D. Grasso, V. Springel and I. Tkachev, Soviet Journal of Experimental and Theoretical Physics Letters 79 (2004) 583.
  * [2] J. A. Bellido, R. W. Clay, B. R. Dawson, M. Johnston-Hollitt, Astroparticle Physics 15 (2001) 167.
  * [3] M. Takeda et al., Astrophys. J. 522 (1999) 225.
  * [4] E. M. Santos et al., Proc. 30th International Cosmic Ray Conf., Merida, Mexico (2007).
  * [5] S. Mollerach et al., Proc. 30th International Cosmic Ray Conf., Merida, Mexico (2007).
  * [6] D. Ivanov et al., Proc. 30th International Cosmic Ray Conf., Merida, Mexico (2007).
  * [7] R. U. Abbasi et al., Astrophys. J. 623 (2005) 164.
  * [8] M. Fukushima, Institute for Cosmic Ray Research Mid-term (2004-2009) Maintenance Plan Proposal Book “Cosmic Ray Telescope Project”, Tokyo University, Tokyo, Japan, 2002.
  * [9] P. G. Tinyakov and I. I. Tkachev, Theoretical Physics Letters 74 (2001) 445.
  * [10] D. Harari et al., Proc. 30th International Cosmic Ray Conf., Merida, Mexico (2007).
  * [11] A. M. Hillas, Ann. Rev. Astron. Astrophys. 22 (1984) 425.
  * [12] V. S. Berezinskii, S. V. Bulanov, V. A. Dogiel and V. S. Ptuskin, Astrophysics of cosmic rays, Amsterdam: North-Holland, 1990, edited by Ginzburg, V.L., 1990.
  * [13] J. Abraham et al., Science 318 (5852) (2007) 938.
  * [14] Pierre Auger Collaboration, arXiv:astro-ph/0712.2843, Dec 2007.
  * [15] R. U. Abbasi et al., arXiv:astro-ph/0703099, Feb 2008, accepted for publication by Phys. Rev. Lett.
  * [16] P. Sokolsky, Proc. 30th International Cosmic Ray Conf., Merida, Mexico (2007).
  * [17] L. Perrone et al., Proc. 30th International Cosmic Ray Conf., Merida, Mexico (2007).
  * [18] M.-P. Véron-Cetty and P. Véron, Astron. Astroph. 455 (2006) 773.
  * [19] C. B. Finley and S. Westerhoff, Astroparticle Physics 21 (2004) 359.
  * [20] P. Tinyakov and I. Tkachev, Phys. Rev. D69 (2004) 128301.
  * [21] R. Atkins et al., Astrophys. J. 595 (2003) 803.