Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
Architecture and security in ASILO¶
Explanatory ASILO 0.1 guides. Illustrative models and profile templates support its application; they add no requirements and impose no universal architecture.
ASILO bounds systems built with artificial intelligence (AI) assistance. This walkthrough explains responsibilities, contracts, data, permissions and effect points. It can apply to an interaction with a model, one agent or several: each requirement retains its application condition and exceptions. AI scope explains these situations.
A layered architecture organises responsibilities. Authorisation decides whether a specific action may be performed on a resource. Both controls need their own evidence.
The building analogy¶
A building separates work areas, services and access. Opening reception does not grant access to the archive. A plan shows connections; locks and their maintenance determine usable access.
In software, layers separate responsibilities and capabilities limit actions over resources. Import rules and authorisation controls address different problems: a program may respect every layer yet authorise the wrong action.
| Question | Decision and check |
|---|---|
| What does each part do? | Declare core, contracts, adapters and composition where that model is relevant. |
| What may depend on what? | Declare dependency direction and check it using the profile's mechanism. |
| Who may act on this resource? | Authenticate the identity and authorise the specific operation at the point of effect. |
| How is authority bounded? | Declare resource, operations, validity and revocation, then test the controls. |
| How do we know it works? | Gather positive and negative tests, configuration, version and results. |
A small example¶
An application can read and delete documents. Logic defines each action; a contract describes access; an adapter operates on files. Authorisation checks identity, document and operation before the effect. A negative test attempts deletion with read-only permission and checks that rejection leaves the document intact.
The example gives a testable criterion. It chooses no library, identity provider, cryptographic algorithm or universal structure.
Security walkthrough¶
| Stage | Reviewable output | Read |
|---|---|---|
| Delimit the system | Assets, actors, inputs, boundaries and effects. | Threat model. |
| Choose responsibilities | Dependency model and exceptions. | Layers and rings. |
| Limit each action | Authorisation contract and point of effect. | Capabilities and effects. |
| Check boundaries | Positive and negative scenarios with results. | Evaluation. |
| Evolve with evidence | Profile, revision, change decision and limits. | Profile and evolution. |
Architecture and security terminology complements the general glossary. Repeat the stages when resources, dependencies or effects change. A small useful part still needs the controls relevant to its context; size alone does not establish security.
Continue with layers and rings, ASILO controls and evaluation. See capability, port and authorisation.
Application controls · Accepted requirements.
Background and knowledge areas¶
The ring model is explained through its documented background. Analogies across disciplines compare protection, compartmentalization, regulation and evidence with explicit limits. Areas and contexts help distinguish reading topics, use situations and architectural layers.